https://texlution.com/post/elixir-concepts-for-golang-developers/

Именн атомизация на функции, а не SOA, как всегда было раньше

Говно, я считаю.

Говно, если разбивать буквально на каждую функцию. В целом я более, чем за.

То бишь, микросервисы — хорошо, но не нано.

То бишь, микросервисы — хорошо, но не нано.

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

как усложнится тестирование, если даже юнит тесты или приемные тесты ты пишешь на часть кода/фичи, а не на весь монолит сразу?

черт сломит ногу в 50+ сервисах. я тебя умоляю :) в 50 сервисов можно онлайн магазин засунуть, а это чуть сложнее сайта визитки

у меня по микросервисам всегда основной вопрос, это хранение в гите) либо свалка в одном месте либо овер 200 репозиториев

Это я просто о наболевшем в моем рабочем, кровавый энтерпрайз, тестирование всего продукта в целом, а он очень большой

ну кровавый энтерпрайз как правило писался на джава5

ну а у нас на плюсах)

красота какая )

боль неимоверная

самое крутое это сборка ядра - 12 часов)

ну еще бы :D

а какая предметная область?

электронная документация

документооборот?

а-ля гос структуры, налоговая и все что рядом

именно так

я думаю даже название продукта знаете, но называть не буду)

да их не много в РФ)

Забавно, в теории микросервисы как раз должны спасать от пересборки всего.

если я верно понял о чем, то история его тянется с 96-97 годов

:D

Забавно, в теории микросервисы как раз должны спасать от пересборки всего.

конечно, монолит был бы намного хуже

вам просто китайцев нужно больше в проект

те умеют чудеса пересборок и оптимизаций делать

вам просто китайцев нужно больше в проект

в этом и проблема! много неквалифированных сотрудников, отсюда неправильное взаимодействие сервисов

и часто вообще непонятно что это и зачем

а как вы деплоите? :D

12 часов это сильно, конечно )

автотесты как проходят и прочее

Я, конечно, сам не то чтобы сильно квалифицированный, диплом сижу дописываю, но страшного много насмотрелся, есть люди которые не хотели переводить бл с винды на линукс, потому что А ЧТО ТАКОЕ ЛИНУКС, Я НЕ УМЕЮ

а как вы деплоите? :D

Тоже хотел спросить про CI/CD, discovery, но боюсь там что-то своё :)

а это всё вместе 12 часов в дженкинсе, параллельно все тесты и сборки на разные ОС

ci самый обычный, просто дженкинс автоматически собирает из гита

деплоймент свой, даже отдельный сервис написали

но зато он умеет откатывать:D

Да, собрать то не беда. А вот доставить, запустить.

они сразу серверы переключают :D

и доставщик это индус с флешкой

суровый деплоймент из девяностых )))

(шучу конечно)

как раз с ним более менее наладили)

а вот прикладные сервисы боль

ну ладно, только я вам ничего не говорил?

?

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

Ага.

Я надеялся, что кто нибудь скажет, что всё не так, и как надо правильно)

суровый деплоймент из девяностых )))

Осталось только папочку расшаренную вместо dcvs

дерево папочек, v1, v2, v100500

ну раз папочка, а не директория, тады "новая папка N" :)

Мы строим на микросервисах, у нас каждый микросервис выполняет какую либо одну задачу, предоставляет http api, и запущен в докер контейнере, под каждый микросервис свой репозиторий. Связанность между сервисами крайне низкая. Сейчас порядка 40 микросервисов. Есть свои грабли, но в целом подход очень ок.

+1 у нас так же. Собирается и тестируется ci в имеджи, потом имеджы через registry пулом на продакшн.

ну раз папочка, а не директория, тады "новая папка N" :)

Новая папочка

Новый папка

Добро пожаловать в чат "Golang RU", I M, агент без юзернейма! Добро пожаловать в чат русскоязычного комьюнити языка программирования Go! Здесь не любят и активно карают за: — оскорбления; — nsfw контент; — флуд, флейм и спам; — избыток оффтоп тем; Список всякой всячины: https://github.com/avelino/awesome-go Ништяки: https://github.com/golang/go/wiki/Projects Сайт комьюнити: http://4gophers.ru/ Список проектов, которым нужны контрибьютеры: https://github.com/ninedraft/gocryforhelp Приятно провести время! :3

ребят, кто-нибудь генерил формы в xlsx на 100 000 строк и примерно на 100 столбцов? ну я про то, что на этом диапазоне будет все данными забито. насколько вообще такая процедура затратная в плане ресурсов? пытаюсь понять либо я дурак, либо конкретно генерация тормозит. потребляет примерно 3гб оперативки на такие масштабы. хочу понять норм или не норм :)

а какая цель конечная? может csv проще сделать?

xlsx это xml

csv тоже есть.

ребят, кто-нибудь генерил формы в xlsx на 100 000 строк и примерно на 100 столбцов? ну я про то, что на этом диапазоне будет все данными забито. насколько вообще такая процедура затратная в плане ресурсов? пытаюсь понять либо я дурак, либо конкретно генерация тормозит. потребляет примерно 3гб оперативки на такие масштабы. хочу понять норм или не норм :)

Как на счет потоквой записи в файл csv?

нужен и csv и xlsx

цель - форма для печати для аналитиков. многостраничная.

xlsx = zip + xml

я это понимаю

не нужно юзать либы, все примитивно и потоком писать

я на пхп такое могу написать и память не потечет :D а тут голанг

киньте ссылкой если есть, как реализовать подобное )

киньте ссылкой если есть, как реализовать подобное )

https://golang.org/pkg/encoding/csv/#NewWriter

кстати да там был какой то из версий xlsx в который можно было как в текстовый файл писать

киньте ссылкой если есть, как реализовать подобное )

Не уверен что потом можно будет сделать из CSV XLSX

ну csv то я сделал отдельно. я тоже думал над тем, что можно как-то вручную xlsx собрать, но нигде не нашел внятной инфы.

ну ладно, в любом случае спасибо. буду думать в этом направлении теперь.

https://en.wikipedia.org/wiki/Office_Open_XML

https://en.wikipedia.org/wiki/Microsoft_Office_XML_formats

https://habrahabr.ru/post/140352/

это голанг, тут только написать своё :)

задача нетривиальна

ага, спасибо. про то, что надо писать своё я уже понял с первых дней на Го ))

изначально думал на петоне написать, но теперь думаю петон бы офигел еще больше от таких объемов :)

да ты орешь )

это не объемы

это потоковая запись в файл

да это всё понятно, но конкретно с либами для xlsx это уже не потоковая запись в файл. я про то как реализовано уже в существующих либах

так то csv у меня генерится за секунды, тут спору нет. с теми же данными.

xlsx это сжатый xml

эт я знаю, ага

карта сайта упакованная

а-ля

просто структура другая

zip — вызов внешнего приложения

там делов то - хедер + контент + футер

вызов зипа

я на делфе 10 лет назад писал в качестве тестового задания