eriksencosta

A production-ready AWS Organization foundation built with Terraform. This template codifies years of multi-account AWS best practices into a reusable, community-friendly blueprint.

In my previous job, we had a mid-sized team of ~34 software engineers and Kotlin worked like a charm. We set common standards and practices early on and it paid off. The lone wolves will exist regardless of the programming language. I've seen them in different flavors: Ruby, Elixir, PHP, JS, Python, Perl, Java, Kotlin, and etecetera throughout my career. It's a matter of team dynamics.

Anyway, I'm not a Kotlin die-hard but I found it quite fun to code in the language. IMHO, it has a gentle learning curve and the community has plenty of great libraries (e.g., Ktor, Koin).

Nevertheless, I think I leaned too much on using the syntactic sugar of the language when writing the docs and the introductory article. But by no means users are bound to this way of coding.

It's a shame I can't travel back in time. Anyway, thanks!

Not yet to Android (in the case of the library). Need to revamp some internal things.

I think it helps to have the inputs and outputs of the system fully representing a "money" (i.e., a monetary amount + its currency code in places like API resources, events, and so on). This way you can internationalize or support multi-currency processing if that's the case. That's (if I remember correctly) what the payment card services companies (e.g., Mastercard, Visa) do by default in their message exchanges when calling the issuer for transaction confirmation.

Anyway, the allocation may be tweaked to favour where the additional/missing pennies will be allocated. You can find more at: https://github.com/eriksencosta/money/blob/trunk/docs/usage/...

HALF_EVEN by default using the minor units of each currency (based on CLDR/ICU datasets). Client code can disable rounding at all.

Check for more: https://github.com/eriksencosta/money/blob/trunk/docs/usage/...

What do you think of this? https://github.com/eriksencosta/money/blob/enum-percentage-s...

It is a (quick) spike solution, but I've implemented the currency codes as enums and added support for 20.percent.

Not so sure about supporting 50.btc and 25.3.usd. I need to check if doing so would affect code completion.

Excel macros.

Yep, it is. However, you must create a custom currency to arbitrarily define the minor units you need: https://github.com/eriksencosta/money/blob/trunk/docs/usage/...

I love to learn more about the history of computing. Thanks.

The currency exchange support is way simpler than this. The library only provides a method that will calculate the monetary amount given another Money object as the rate:

val amount = 1 money "USD" // USD 1.00

val rate = 5.4905 money "BRL" // BRL 5.4905

amount exchange rate // BRL 5.49

It's up to implementers to hook up in other datasets and to consume the rates. Exchange rates datasets differ from country to country and some foreign exchange companies offer short-term contracts to hold a transaction at a given rate (sort of "guaranteed rate/price"). I don't see myself supporting this use case.

Nevertheless, Java Money (Moneta) has this feature. Never used it so, I don't know how it works.

I'm very grateful so far by the comments. I've learned a lot and it will help me on the next iterations of the library.

Thanks for commenting! I'm still learning Kotlin and I overlooked the usage of get() with vals. This will be the next syntactic sugar into the mix. I think it makes sense.

When I was designing the API, I created methods like toUSD() and toEUR(). But with 306+ circulating/tender currencies and 2000+ cryptocurrencies, I thought it could lead to a bad experience when using code completion.

Great reference, Sam. I will definitely bookmark your library and learn with your implementation.

For cryptocurrency data, take a look at the DTIF.org dataset: https://github.com/eriksencosta/money/blob/trunk/docs/append...

You don't need if your solution fits your use case. The library is an implementation of Fowler's Money pattern: https://martinfowler.com/eaaCatalog/money.html

Thanks for commenting. I'm still learning Kotlin and I overlooked the usage of get() with vals. This will be the next syntactic sugar into the mix. I think it makes sense.

When I was designing the API, I created methods like toUSD() and toEUR(). But with 306+ circulating/tender currencies and 2000+ cryptocurrencies, I thought it could lead to a bad experience when using code completion.

The library will throw an exception if doing an operation with different currencies: https://github.com/eriksencosta/money/blob/trunk/money/src/t...

But I think I'll make it explicit in the documentation. Thanks for pointing out!

I'll introduce l10n support in a future release. My starting point was to make currency names and symbols unaware of the locale as I embedded cryptocurrency data in the mix.

Anyway, the library uses the CLDR dataset through ICU: https://github.com/eriksencosta/money/blob/trunk/docs/append...

Languages indeed have support for currencies and decimal numbers. My implementation is based on Fowler's Money pattern. The Money object is thus a value object representing a monetary amount in a given currency.

https://martinfowler.com/eaaCatalog/money.html

You are right. Languages indeed have support for currencies and decimal numbers. My implementation is based on Fowler's Money pattern. The Money object is thus a value object representing a monetary amount in a given currency.

This is great!

Joda is impressive and has great performance.

The examples were written using the infix notation but you can just use regular method calls. For example:

val price = Money.of(100, "USD")

val shipping = Money.of(5, "USD")

val subtotal = price.plus(shipping)

val discount = Percentage.of(10)

val total = subtotal.decreaseBy(discount)

total.allocate(2)

total.allocate(60.percent(), 40.percent())

Thanks for the questions. Answers:

1. You get an exception

2. You may specify the rounding rule: https://github.com/eriksencosta/money/blob/trunk/docs/usage/...

3. It has some parsing capabilities. The extra digit is kept, rounding is only applied when doing an operation with the Money object

4. Same as 2

I think I will add a footnote on COBOL. COBOL is huge in Brazil, lot of insurance/financial companies are still using mainframes.

This is something I am aware but there is no support for this rounding scheme at the moment.

I couldn't agree more as someone who has been using more spreadsheets than actually coding in the last 10 years.

In Brazil (where I worked) we used Kotlin + Ktor. In Europe, they are heavy Kotlin users.

References:

Brazil: https://blog.eriksen.com.br/en/platform-engineering-n26 Europe: https://medium.com/insiden26/engineering-at-n26-a-tour-of-ou...

Oh sorry, that's a typo. Thanks for pointing out!

It uses BigDecimal. My first goal with the library was to provide a well-designed API. So to keep it simple for myself, I relied on BigDecimal for the calculations.