Money.js is a tiny (1kb) JavaScript currency conversion library for web & nodeJS | Hacker News Reader

Money.js is a tiny (1kb) JavaScript currency conversion library for web & nodeJS

josscrowcroft.github.com

96 pointsjosscrowcroft34 comments

As nice as this is, there's a fly in the ointment. Google (from where the exchange rates are harvested) Terms & Conditions:

> 5.3 You agree not to access (or attempt to access) any of the Services by any means other than through the interface that is provided by Google, unless you have been specifically allowed to do so in a separate agreement with Google. You specifically agree not to access (or attempt to access) any of the Services through any automated means (including use of scripts or web crawlers) and shall ensure that you comply with the instructions set out in any robots.txt file present on the Services.

> 5.5 Unless you have been specifically permitted to do so in a separate agreement with Google, you agree that you will not reproduce, duplicate, copy, sell, trade or resell the Services for any purpose.

Good catch, thanks for that - though this only concerns the open source exchange rates API, not money.js - which can use any fx rate data you give it (including paid services, not that I plan to offer one.)

edit: That said - and even though we're semi off-topic - I contest that the google calculator API has no restrictions with being accessed by scripts or crawlers.

Note that their T&Cs under section 5.3 specify compliance with any 'robots.txt' file on the domains. In http://www.google.com/robots.txt, there is no mention of the /ig/calculator subdomain being prohibited to robots.

Also, under 5.5, the service isn't actually being duplicated, copied or resold.

Any thoughts on that?

And, technically, aren't you accessing the Services through the interface provided by Google when you access their public API?

Yes! Having said that, I'm not taking any chances - I don't expect to hear from them, but will attempt to get an answer from Google as to whether this is ok.

I'm rewriting the scraper right now to use a different service with a more friendly TOS pending further investigation - can't afford a legal battle over this!

You might find this article, "Considerations on Exchange Rate Data Providers", useful: http://www.currencysystem.com/kb/13-143

It's from the website of the Cloanto system and has some ideas on publicly available FX feeds.

Cool project! Any plans for JSONP support?

I assume you're talking about the open source exchange rates API - will soon have JSONP support via the openexchangerates.org proxy, for sure - so like normal, you'll be able to go `callback=lolwut` or whatever you need.

The website says "The ‘API’ is powered by a simple nodeJS scraper" so I got the impression that you were screen scraping the search page. Consuming an API is typically not considered scraping.

It's not obvious (and IANAL) whether an undocumented API is "provided", but the bigger stink IMO is your re-licensing of the data. The data is unquestionably copyright Google, license unknown. I'd get rid of the license-tag: You're giving the world a license to re-distribute some data that may very well not be yours to distribute in the first place.

Finally, providing data for download in a neatly packaged format would qualify as duplicating and copying in my reading.

FWIW, http://www.google.co.uk/intl/en/help/currency_disclaimer.htm... must be assumed to cover access through the API as well.

> Foreign currency rates provided by Citibank N.A. are displayed under licence.

That's fair. I pointed out somewhere in the docs that I'm open to people contributing improvements to the legals, including the license and disclaimer. For me, the important thing is that the data is available, for free and on-demand. I don't much care what license it's under, but I know that many people do.

Data cannot be copyrighted. Only creative works (defined loosely enough to include Michael Bay films) are covered by copyright law.

Yes, I was talking about https://raw.github.com/currencybot/open-exchange-rates/maste... + &callback=something

Great news :) Thanks

I am always impressed by how nice these libraries are presented. Great font, beautiful color scheme, pretty layout, etc... It's hard enough for me to write some good code, let alone write some good code then build a beautiful landing page for it. Is there some sort of template service everyone uses that I don't know about? Or do you guys just take a lot of time building these presentation pages because it's part of writing great code?

In fact. I would venture to say one of the best indicator for the quality a library or plugin, is how well it's presented in html.

Does anyone else notice this?

I think its just representative of the creators passion for the work being created. If one is to spend a good amount of time and effort in the creation of a library, and they feel its as good as it should be, then it follows that it deserves good presentation. So I agree, but I can imagine it helps to be a competent creative[1], to pull off a good presentation.

[1]: in the loose sense of the word.

Glad you like it, thanks!

The homepage for this and the exchange rates API was designed in-browser, i had a lot of time on my hands thanks to two back-to-back 8 hour flights.

Naturally it's based on the HTML5 boilerplate (http://www.html5boilerplate.com) - HTML done by hand, but if there is a template service, I'd love to know about it.

The colours are mostly taken from Solarized Dark colour scheme and modified a bit: (http://ethanschoonover.com/solarized)

And the sandbox demo console is something i threw together just for this but released on github (http://josscrowcroft.github.com/javascript-sandbox-console/)

PS The robot (currencybot) came from http://robohash.org using the text 'CurrencyBot' :)

Interesting you say this. I totally agree, and I have had a 'back burner' idea for the past year or so now of creating a simple template generator for libraries/such projects. I really need to start working through that list! :-)

That sounds like a laugh - would love to help out if poss, let's talk it out!

This doesn't appear to address any of the numerical issues with representing money in floating-point numbers. I assume it's just meant for client-side previews and estimates?

If you're doing accurate conversions on the server side, I guess I don't see the advantage to doing different conversions that yield different results on the client side.

It's true that representing currency in floating-point vars is never going to be 100% accurate - but for price quotations, estimates and convenience, you can get pretty accurate results (provided you have accurate exchange rates)

Remember of course that any currency conversion will always carry inaccuracy, because every time money changes currency, somebody takes a cut.

I recommend using this alongside some other numbers-related library (such as accounting.js) to fix binary value rounding issues (and also for decent formatting)

Out of interest, what do you consider to be "accurate conversions on the server side"?

If I had to do accurate calculations from scratch, I would probably used fixed-point or arbitrary-precision math, talk to an accountant about industry standards and carefully cover my edge-cases for rounding and the like. More practically I would try to use a well-established library. I can't recommend anything specifically.

It's not impossible to do accurate calculations in JS, but my main point is that since the only built-in way to do math is floating point it's a bit of a minefield to go with a naive solution.

Fair play. I definitely wouldn't feel good recommending money.js for any application where people live and die by the 8th point of precision on an exchange rate, if you know what I mean - but it's a solid solution for estimates, price conversions and most enterprise software - provided that appropriate disclaimers are given (i.e. "converted prices for informational purposes only") - everyone should cover their arses.

I agree with you though, that there will be the 1% of cases where something a lot more reliable is needed, but I imagine that's when you call in the CS heavyweights.

This is pretty cool.

Is there any particular reason for the name 'fx', though? Seems a bit strange for a global variable name to be a two letter string that could be used relatively commonly as a variable name in browser-land.

Aside from that, I love it!

Looks like you can use fx.noConflict() to work around possible global conflicts.

I thought that might come up and maybe should clear it up in the docs - `fx` is a term used often in finance or accounting to refer to forex or, loosely, 'currency'

So, in our analytics application, we have multiple currencies represented in one table, the result being that we have a separate column for "currency" (next to e.g. "revenue") which is shortened to "fx".

It is definitely a potentially common global variable name though, so there's a handy `noConflict` method that can be used to assign the library to another var (eg `money`), and restore the previous global value of `fx` before moneyjs was loaded.

Eg:

    var money = fx.noConflict();
    // now it's `money.convert()`, and `fx` is whatever it was previously

Also, if using money.js as a node package or AMD module, you simply assign it to whatever you like:

    var moneyBro = require("money"); // no need for `fx`

Having said that, I think it works nicely as a namespace, if confusion can be avoided

Or you could just call it CurrencyConverter and let me say var fx = new CurrencyConverter(), deciding if I want it to be called that. Global clobbering should be opt-in, not opt-out.

That might not work so well with the structure of the library, but I'm open to calling it something else, if enough people say it's an issue - so feel free to fork it and do a pull request.

moneyjs-noconflict.patch:

  --- money.js
  +++ money.js
  @@ -13,6 +13,8 @@
   		return new fxWrapper(obj);
   	};
   
  +	var NS = 'CurrencyConverter';
  +
   	// Current version.
   	fx.version = '0.0.1';
   
  @@ -122,28 +124,14 @@
   	// Otherwise, just add `fx` to the global object
   	if (typeof module !== 'undefined' && module.exports) {
   		module.exports = fx;
  -		fx.fx = fx;
  +		fx[NS] = fx;
   	} else if (typeof define === 'function' && define.amd) {
   		// Return the library as an AMD module:
   		define([], function() {
   			return fx;
   		});
   	} else {
  -		// Use fx.noConflict to restore `fx` back to its original value before money.js loaded.
  -		// Returns a reference to the library's `fx` object; e.g. `var money = fx.noConflict();`
  -		fx.noConflict = (function(previousFx) {
  -			return function() {
  -				// Reset the value of the root's `fx` variable:
  -				root.fx = previousFx;
  -				// Delete the noConflict function:
  -				fx.noConflict = undefined;
  -				// Return reference to the library to re-assign it:
  -				return fx;
  -			};
  -		})(root.fx);
  -
  -		// Declare `fx` on the root (global/window) object:
  -		root['fx'] = fx;
  +		root[NS] = fx;
   	}
   
   	// Root will be `window` in browser or `global` on the server:

You can change NS to whatever you like, but I believe that this is all you need to do. Because everything internally uses the enclosed `var fx`, I don't foresee issues.

Thanks for sharing this! I'm pretty sure I'll use it in a few months for our coming SAAS.

And by the same author: http://josscrowcroft.github.com/accounting.js/

Use in conjunction with my currency guesser for maximum win: https://github.com/jasondavies/lang-currency.js

It guesses the most likely currency given the user's IETF language tag and a list of supported currency codes.

@josscrowcroft great job, this, and your accounting.js contributions (creations), keep up the good work

Cheers dude!

This is great. I could see us using this library at Forbes.

Sweet - I'd love to hear if you do!

This is slick. Thanks for sharing.

Reply on news.ycombinator.com