umm-csci-systems / currency-exchange-rpc Goto Github PK

The test code refers to "dummy" data in my home directory, but the URL is still www.morris.umn.edu when it should now be facultypages.morris.umn.edu. This needs to be changed or people get a redirect HTML page instead of the desired JSON.

I have the two methods they have to write throw UnsupportedOperationExceptions as a way of ensuring that the tests fail without having to return a value to get the code to compile. This has occasionally confused people, and the level of confusion seems to be growing over time as people's use of Java decreases.

We should probably add a bit to the write-up explaining why that's there or (perhaps better?) add a comment to the code explaining why that's there and making it clear that they can and should remove it when they insert their code.

The numbers returned by http://fixer.io don't quite match the old numbers from XavierMedia, so the tests need to be updated to match those values. I'm not at all sure why the numbers are different; maybe they're reporting the rates from a different point in the day?

This currently uses the Xavier Media exchange rates API, which has worked well for us. The two downsides are (a) it's a private company, and we have no idea how long they'll keep wanting to provide this service and (b) it only returns XML, when JSON would arguably be the more sensible format these days.

The second issue can be fixed by switching to something like fixer.io, which provides the exchange rate data in JSON format. It's free, requires no registration, seems fast and reliable, and is open source on Github. There's no particular reason to believe that it will run forever, but since it's open source we could presumably set up our own server if we wanted/needed to; they even have docker instructions to make that easier, which is cool.

There are a number of other services, but almost all of them require at least some sort of registration, which we don't really want for a class.

The European Bank provides data for free, but it's in XML, and doesn't seem to provide a general purpose API (at least not that I can make sense of).

There was confusion about where the access code goes in the URL, and in particular what happens if we provide an access code in calls to the Morris web server. It (happily) turns out that our server ignores the access code and the tests work and pass, but that was confusing for some of the students.

We should also say something about reading access codes from etc/access_keys.properties in readAccessKeys(), as well as explaining the need to copy access_keys.properties.sample over to the "secret" version that is ignored by git.

https://dev.to/afrodevgirl/replacing-master-with-main-in-github-2fjf

Make sure to update any existing pull requests as well.

If we stick with Java, it would be nice to clarify some of the intentions in ExchangeRateReader. Students frequently have a ton of questions about what I was thinking when I set up that class, and aren't sure how to get started. The constructor, for example, often confuses people a lot, where people assume that a lot of stuff needs to happen there, when in fact all I did was store the baseUrl in a field.

The URL in the last test has the date cooked in and a stub for the access key. This should all be removed because the date and access key should be added to the URL by their code.

Now that we're using http://fixer.io we need to use access keys. 😢 This means we need to have a reasonable way to handle those where they won't get committed. I think we want to create a "secret" file that the code will read, and we add that file to .gitignore to make sure that we don't commit that and make it public.

We're not using Eclipse anymore for projects, so we really should remove those files.

Paul seems to think that the "modern" solution to this access key business is via environment variables and not through things like property files. I should do some homework and figure out what people are using, and migrate it into this lab if/as appropriate.

Students have frequently had trouble understanding the structure that I intend in the skeleton we provide. They often want to "do fancy things" in the constructor, for example, when all they need to do is capture the provided URL in a field.

Several past issues have been connected to this, including #3, #10, and #11.

In a conversation with @cole-maxwell1 and @zeus-ctrl it was suggested that what we want to do is go over Main.main() in the write-up. If we explain what's happening in that code, it might help clarify what needs to happen in the various methods that it calls, including the constructor and the conversion methods.

In a conversation with @helloworld12321 and @RichardLussier they also had questions about

• The role of the main() - did they need to change anything there? Was the point to get the main to work? Did they have to even run it?
• What (if anything) did they need to change in main()?

I should probably add some text that explains that the point here is to write a library (not an app), and that main() is just there so you can play with things. It's also worth mentioning:

• If you are happy only using the dates I provide, you can leave the URL pointing at my pages.
• If you want to use other dates, you would have to switch the URL to use Fixer.io.
• The date is hard-coded; if you want different dates you'd need to add code that prompts for date info.

It would be useful both for the students and the TAs.

I'm not sure how complicated the whole access key thing gets here, though. One option would be to put some sort of tag/test group thing on the fixer.io test and tell the command line test runner to ignore that test.

Especially if we change from XML to JSON, it might make sense to switch this lab from being in Java to being in JavaScript. I'm not sure if that would be a server side thing (i.e., Node) or a client side thing happening in the browser?

I added some instructions on how to compile and run this code outside of Eclipse to the Fall 2016 version of the lab, and I need to pull those back into this copy of the project.

A the moment we're using an ignored file to hold the API key, but I think the "right" way to do that these days is via environment variables. I think that if we did that we could also get the GitHub Actions to work correctly with secrets, whereas they can't if we stick to an uncommitted file.