Exchange Rates By Google Finance

[MartyIX]

Hello,

 

  I examined Google Finance exchange rate processor (/components/exchange_rates/google_finance/google_finance.php) and it seems that it no longer works because the URL http://www.google.com/ig/calculator is not working any more. I believe that it was shutted down together with iGoogle by Google.

 

Could anybody confirm this?

 

Thank you!

 

 

Blesta version: 3.0.6

[Paul]

I have confirmed Google has changed the URL and I have assigned this to CORE-879 so we can take a look into it. Thanks for the report!

[Cody]

Updated to use google's new currency API. CORE-879 fixed in 3.0.7.

 

Overwrite the attached file to use the new API in /components/exchange_rates/google_finance/

google_finance.php

[Michael]

Updated to use google's new currency API. CORE-879 fixed in 3.0.7.

 

Overwrite the attached file to use the new API in /components/exchange_rates/google_finance/

 

Thanks mate.

[dait]

How is that Blesta devs do not have any code that alerts them in case something like this stops  working? This is not a good style of software development guys.

[Michael]

How is that Blesta devs do not have any code that alerts them in case something like this stops  working? This is not a good style of software development guys.

 

No company does it. WHMCS would of died by now. Hostbill, well they would of died too. Microsoft... well I won't get into that. 

[dait]

Sorry, not a good argument for me, or I do not understand your point.

 

Unit testing is common practice and it seems especially important to automatically and periodically execute tests that verify whether third party components that one has no control of work properly.

 

It is not a good idea to write a working code once and not to check it again in case it relies on third parties.

 

Not only these and similar practices allows developers to quickly react to new problems it also makes the whole project easier to maintain and faster to develop. Things like unit tests, debug modes, logging etc.

[Michael]

Sorry, not a good argument for me, or I do not understand your point.

 

Unit testing is common practice and it seems especially important to automatically and periodically execute tests that verify whether third party components that one has no control of work properly.

 

It is not a good idea to write a working code once and not to check it again in case it relies on third parties.

 

Not only these and similar practices allows developers to quickly react to new problems it also makes the whole project easier to maintain and faster to develop. Things like unit tests, debug modes, logging etc.

 

You don't understand, it's not Blesta's fault Google changed their API recently.. they don't work for Google.

[dait]

So, it is not Blesta's fault that part of their SW did not work for unknown period of time and possibly affected its users even if using common development practices would allow to reveal and fix this the same day the problem occurred?

 

You must be joking

[Paul]

There probably should have been a unit test for this, point taken. We may have been able to discover and resolve the issue sooner.

 

But lets look at what happened..

 

10:15am issue reported

4:37pm hotfix issued

[dait]

I am very glad that the issue was fixed that quickly, thank you for that and no doubt about good active response here.

 

Besides unit test, it would be nice if Blesta did not silently overcome failures. This is not the only case. There are many code parts in Blesta which look like this:

result := functionCall();
if (result)
{
  do the stuff
}

instead of like this:

result := functionCall();
if (result)
{
  do the stuff
}
ELSE TELL ADMIN WE HAVE A PROBLEM

So even if the issue is missed by devs, which can happen, the users (admins) will know just after the problem occurred and can report to devs and/or act otherwise. But if we do not know that some part is broken, we could run into hard troubles, depending on the character of the issue. Not knowing is the worst evil. You expect everything works as it should, but it does not. This could cost us a lot if circumstances were extraordinary bad.

[MartyIX]

Paul: This is not an issue of your dedication to fix issues. The issue was resolved very fast, thank you for that. Yet, a unit test is a cheap way how to assure that Blesta still works with minimal amount of work. The source code seems in good shape to create a unit test, so I don't see a reason why there should NOT be a unit test to avoid troubles like this. 

[Cody]

Paul: This is not an issue of your dedication to fix issues. The issue was resolved very fast, thank you for that. Yet, a unit test is a cheap way how to assure that Blesta still works with minimal amount of work. The source code seems in good shape to create a unit test, so I don't see a reason why there should NOT be a unit test to avoid troubles like this. 

 

I've created the unit tests to process all exchange rate processors. We'll be moving to a daily build process soon which will help us catch these types of issues right away.

[dait]

Nice, thanks