

Money.js is a tiny (1kb) JavaScript currency conversion library for web & nodeJS - josscrowcroft
http://josscrowcroft.github.com/money.js/

======
mseebach
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.

~~~
josscrowcroft
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?

~~~
mseebach
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.

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

------
vinhboy
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?

~~~
petercooper
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! :-)

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

------
RodgerTheGreat
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.

~~~
josscrowcroft
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"?

~~~
RodgerTheGreat
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.

~~~
josscrowcroft
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.

------
Hovertruck
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!

~~~
josscrowcroft
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

~~~
oinksoft
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.

~~~
josscrowcroft
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.

~~~
oinksoft
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.

------
thibaut_barrere
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/>

------
jasondavies
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.

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

~~~
josscrowcroft
Cheers dude!

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

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

------
purephase
This is slick. Thanks for sharing.

