в целом всё не настролько ужасно, чтобы тащить линзы и т.п.

сколько раз хотел заюзать что-то монокле-подобное - оказывалось это чистое ЧСВ и руками проще :)

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

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

по-разному бывает, мне нравится иметь shared модели, пусть это несколько и ущемляет права пуристов микросервисников

по-разному бывает, мне нравится иметь shared модели, пусть это несколько и ущемляет права пуристов микросервисников

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

Если делать сериализацию трейта, то как макросу отличить поля от методов? Ведь даже если сейчас у трейта только поля, не факт, что в будущем так будет. И в зависимости от конкретной реализации макроса в жсон может попасть мусор

Замени трейт на abstract class. Тут уже намного проще все будет - методы отдельно, поля отдельно

Там может и женерик сам подтянется, но я не уверен

Замени трейт на abstract class. Тут уже намного проще все будет - методы отдельно, поля отдельно

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

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

Почему не относится. Нужно сделать сериализацию трейта. Причём с допущением, что все члены трейта - это сериплизуемые поля. Но такое допущение довольно хрупкое, из-за особенностей трейтов в скале. Если будет abstract class вместо трейта - то тут можно будет явно выделить поля и методы, и макрос не развалится в будущем.

Почему не относится. Нужно сделать сериализацию трейта. Причём с допущением, что все члены трейта - это сериплизуемые поля. Но такое допущение довольно хрупкое, из-за особенностей трейтов в скале. Если будет abstract class вместо трейта - то тут можно будет явно выделить поля и методы, и макрос не развалится в будущем.

не относится это потому, что в кейсе Александра - он сам король. По какому принципу решит включать в выхлоп - так и будет, ему для этого ничье одобрение не потребуется особо и вся ответственность будет целиком лежать на тех, кто имеет право коммита без всякой помощи(явной или не явной) со стороны этого самого макроса. а про trait -> abstract class - расскажи в примерах, что вот тут трейт сосет, а абстракт - красавчик, чтобы я мог контраргументировать в конкретных местах чтоли)

Я с телефона, так что не расскажу в примерах. Схема с ручным контролем очень хрупкая.

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

Это не так сложно, и может шейплес так умеет

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

ну так это уже другой контекст - это уже не фильтрация боди класса и гадание на кофейной гуще кто есть кто, а явный перечень аргументов праймари конструктора. (ну и не стоит забывать, что его уже не примесить никуда - придется наследовать)

ну так это уже другой контекст - это уже не фильтрация боди класса и гадание на кофейной гуще кто есть кто, а явный перечень аргументов праймари конструктора. (ну и не стоит забывать, что его уже не примесить никуда - придется наследовать)

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

давайте без "упырей".

Ого, мощно!

пост бунина по теме. https://www.facebook.com/oleg.bunin/posts/2003812779660403 общаются с РКН, пытаются выработать какие-то механизмы, как я понимаю.

@fomkin с таким в понв

у меня тоже есть небольшой пост на эту тему

wget https://repo.scala-sbt.org/ --2018-05-04 20:42:16-- https://repo.scala-sbt.org/ Resolving repo.scala-sbt.org (repo.scala-sbt.org)... 34.236.44.1, 34.203.50.117 Connecting to repo.scala-sbt.org (repo.scala-sbt.org)|34.236.44.1|:443... connected. Unable to establish SSL connection.

Чем можно считать из csv файла числа и нарисовать в файлик график?

Чем можно считать из csv файла числа и нарисовать в файлик график?

Вопрос больше по второй части. Графики.

@dimstream можно этим попробовать https://github.com/vegas-viz/Vegas или https://github.com/alexarchambault/plotly-scala

@dimstream можно этим попробовать https://github.com/vegas-viz/Vegas или https://github.com/alexarchambault/plotly-scala

Ага, уже читаю, спасиб.

https://github.com/sameersingh/scalaplot

Тоже прикольно, может в ASCII графику (и png, pdf, svg)

может быть удобно для предпросмотра сразу в консоли (в моем случае в тестах)

Лайты книгу про аккуратно выпустили

https://www.lightbend.com/blog/how-akka-works-akka-a-to-z-illustrated-white-paper

очередной маркетинговый булшит

где книга How Akka Doesn't Work

особенно касательно мониторига и кластера

А ты лайтбенд купи плез

все эти книги больше похожи на рекламные буклеты

Ну да , так всегда было

Но они идею общую показывают красиво и наглядно

эта, скалисты, у меня есть очинь глупый вопрос, как нормально округлять деньги? и вообще как нормально округлять BigDecimal чтобы это было как в рашн школе? val money = BigMoney.of(currencyUnit, new BigDecimal(amount).setScale(2, BigDecimal.ROUND_HALF_UP)) делает из 0.805 = 0.80 это несерьезно

все умерли?

.setScale(3)

эта, скалисты, у меня есть очинь глупый вопрос, как нормально округлять деньги? и вообще как нормально округлять BigDecimal чтобы это было как в рашн школе? val money = BigMoney.of(currencyUnit, new BigDecimal(amount).setScale(2, BigDecimal.ROUND_HALF_UP)) делает из 0.805 = 0.80 это несерьезно

Для финансов есть свои правила можно на Вики глянуть

Там в сторону четного вобщем надо округлять

я уже глянул! мать их за ногу всех, https://en.wikipedia.org/wiki/Rounding

и у них там по-моему grade school, универститет, и финансы разные округления

и вопрос, как все-таки правильно округлять эти чертовы деньги?

это же обертка над жабьим BigDecimal. правила округления из jdk

если свои деньги считаешь - округляй вверх. если чужие - вниз.

ну сирьезна жи

чо вы как дети, как округлять бабос?

тебе об этом должен сказать FA

или BA какой-нибудь.

везде свои правила

если нет никаких конкретных требований, то округляй как хочешь

но мне сказали: ва франтенде инвоис выглядит нитак как на печати

и я хочу докопаться до истины

ну копейки отличаются в общм

а стековерфлоу говорит When calculating annual taxes, the fractions are often cut off (RoundingMode.FLOOR). When calculating a bonus, you might want to always round in favor of the customer (RoundingMode.CEILING). For taxes on a bill, you usually round HALF_UP When doing complex financial simulations, you don't want to round at all.

В js на фронте тож могут через анус округлять

ERROR: S client not available

https://github.com/hhandoko/http4s-graal

и как?

но мне сказали: ва франтенде инвоис выглядит нитак как на печати

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

http://degoes.net/articles/effects-without-transformers

https://github.com/hhandoko/http4s-graal

ооооо

http://degoes.net/articles/effects-without-transformers

Backport of the IO Monad to scalaz 7.2 - https://github.com/scalaz/ioeffect

Backport of the IO Monad to scalaz 7.2 - https://github.com/scalaz/ioeffect

Лука уже для котов то же самое написал

Лука уже для котов то же самое написал

разве Лука? Я думал Спивак сначала воплотил эту идею в cats-effects

cats-effect это старый ио

понятно

разве Лука? Я думал Спивак сначала воплотил эту идею в cats-effects

https://github.com/LukaJCB/cats-bio

и по своим бенчмаркам он рвет дегуза

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

Интересная серия статей Романа Чепляки о проблемах MTL и его подходе к решению этих проблем (Haskell) https://ro-che.info/articles/extensible-effects

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

Вы правы

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

у меня и правда было 2 разных округления одного и того же числа

но зато я теперь сколько много всего знаю об округлениях! ?

эта, скалисты, у меня есть очинь глупый вопрос, как нормально округлять деньги? и вообще как нормально округлять BigDecimal чтобы это было как в рашн школе? val money = BigMoney.of(currencyUnit, new BigDecimal(amount).setScale(2, BigDecimal.ROUND_HALF_UP)) делает из 0.805 = 0.80 это несерьезно

Вообще, если у тебя там несложные финансы, то можно попробовать деньги держать в Integer и для округлений держать VatPercentage

Потому что ошибки все равно будут. Например, если посчитать vatPercentage для нескольких инвойсов и потом vatPercentage для всей входящей суммы. Обычно, финансистам более-менее пофиг, поэтому можно применять то же округление, что они у себя для double accounting используют (например quickbooks)

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

Там тема не такая простая

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

Плюсую. В некоторых занятных случаях разные правила для разных ведомств , видов доков , разные способы разбираться с погрешностью( если о гос учреждениях говорить, типа таможни).

https://github.com/oleg-py/better-monadic-for

кто-нибудь впиливал в проект?

приятно что можно делать (a,b) <- either в for-е

относительно свежий проект кстати

Человеки, как лучше спроектировать и что юзать? Есть система и в ней есть (будет) куча препроцессоров данных. Надо сделать так, чтобы их было легко добавлять/убирать из обработчика/комбинировать.

Вспоминаются пайпы из древнего java.io

Но думаю есть же выход лучше?