T-Th 9:05 |
CS 1110: Introduction to Computing Using Python Fall 2016 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Main
About: Announcements Staff Consultants Times & Places Calendar Materials: Texts Python Command Shell Terminology VideoNote Handouts: Lectures Assignments Labs Assessment: Grading Exams Resources: CMS Piazza AEWs FAQ Python API Python Tutor Style Guide Academic Integrity |
Assignment 1:
|
Code | Name | 1 USD = | Code | Name | 1 USD = | |
---|---|---|---|---|---|---|
AED | United Arab Emirates Dirham | 3.673054 | LKR | Sri Lankan Rupee | 145.3018 | |
AFN | Afghan Afghani | 66.648349 | LRD | Liberian Dollar | 91.25 | |
ALL | Albanian Lek | 122.8874 | LSL | Lesotho Loti | 14.50046 | |
AMD | Armenian Dram | 474.772503 | LTL | Lithuanian Litas | 3.042371 | |
ANG | Netherlands Antillean Guilder | 1.776225 | LVL | Latvian Lats | 0.626282 | |
AOA | Angolan Kwanza | 165.560832 | LYD | Libyan Dinar | 1.382368 | |
ARS | Argentine Peso | 14.9529 | MAD | Moroccan Dirham | 9.747332 | |
AUD | Australian Dollar | 1.320113 | MDL | Moldovan Leu | 19.72248 | |
AWG | Aruban Florin | 1.793333 | MGA | Malagasy Ariary | 3034.09 | |
AZN | Azerbaijani Manat | 1.654175 | MKD | Macedonian Denar | 55.03539 | |
BAM | Bosnia-Herzegovina Convertible Mark | 1.752535 | MMK | Myanma Kyat | 1210.41 | |
BBD | Barbadian Dollar | 2 | MNT | Mongolian Tugrik | 2214 | |
BDT | Bangladeshi Taka | 78.27594 | MOP | Macanese Pataca | 7.983968 | |
BGN | Bulgarian Lev | 1.750618 | MRO | Mauritanian Ouguiya | 355.400667 | |
BHD | Bahraini Dinar | 0.376916 | MTL | Maltese Lira | 0.683602 | |
BIF | Burundian Franc | 1662.382495 | MUR | Mauritian Rupee | 35.212262 | |
BMD | Bermudan Dollar | 1 | MVR | Maldivian Rufiyaa | 15.235 | |
BND | Brunei Dollar | 1.358481 | MWK | Malawian Kwacha | 718.338002 | |
BOB | Bolivian Boliviano | 6.919986 | MXN | Mexican Peso | 18.60386 | |
BRL | Brazilian Real | 3.253921 | MYR | Malaysian Ringgit | 4.086328 | |
BSD | Bahamian Dollar | 1 | MZN | Mozambican Metical | 73.154999 | |
BTC | Bitcoin | 0.001743287645 | NAD | Namibian Dollar | 14.53476 | |
BTN | Bhutanese Ngultrum | 66.847366 | NGN | Nigerian Naira | 311.1409 | |
BWP | Botswanan Pula | 10.80355 | NIO | Nicaraguan Córdoba | 28.92108 | |
BYR | Belarusian Ruble | 20026.25 | NOK | Norwegian Krone | 8.319716 | |
BZD | Belize Dollar | 1.997295 | NPR | Nepalese Rupee | 106.9042 | |
CAD | Canadian Dollar | 1.300473 | NZD | New Zealand Dollar | 1.370925 | |
CDF | Congolese Franc | 978.5 | OMR | Omani Rial | 0.384987 | |
CHF | Swiss Franc | 0.980119 | PAB | Panamanian Balboa | 1 | |
CLF | Chilean Unidad de Fomento | 0.025363 | PEN | Peruvian Nuevo Sol | 3.387954 | |
CLP | Chilean Peso | 676.864098 | PGK | Papua New Guinean Kina | 3.1631 | |
CNY | Chinese Yuan | 6.680436 | PHP | Philippine Peso | 46.6189 | |
COP | Colombian Peso | 2962.688333 | PKR | Pakistani Rupee | 104.382699 | |
CRC | Costa Rican Colón | 550.2024 | PLN | Polish Złoty | 3.910263 | |
CUC | Cuban Convertible Peso | 1 | PYG | Paraguayan Guarani | 5524.27 | |
CUP | Cuban Peso | 24.728383 | QAR | Qatari Rial | 3.641308 | |
CVE | Cape Verdean Escudo | 98.526199 | RON | Romanian Leu | 3.985652 | |
CZK | Czech Republic Koruna | 24.2012 | RSD | Serbian Dinar | 110.16216 | |
DJF | Djiboutian Franc | 177.5225 | RUB | Russian Ruble | 65.254741 | |
DKK | Danish Krone | 6.665392 | RWF | Rwandan Franc | 801.921751 | |
DOP | Dominican Peso | 45.99992 | SAR | Saudi Riyal | 3.750157 | |
DZD | Algerian Dinar | 109.33054 | SBD | Solomon Islands Dollar | 7.841384 | |
EEK | Estonian Kroon | 14.0068 | SCR | Seychellois Rupee | 13.15168 | |
EGP | Egyptian Pound | 8.875947 | SDG | Sudanese Pound | 6.073008 | |
ERN | Eritrean Nakfa | 15.4 | SEK | Swedish Krona | 8.57748 | |
ETB | Ethiopian Birr | 22.09099 | SGD | Singapore Dollar | 1.359871 | |
EUR | Euro | 0.8963 | SHP | Saint Helena Pound | 0.75217 | |
FJD | Fijian Dollar | 2.05045 | SLL | Sierra Leonean Leone | 5610.5 | |
FKP | Falkland Islands Pound | 0.75217 | SOS | Somali Shilling | 582.742167 | |
GBP | British Pound Sterling | 0.75217 | SRD | Surinamese Dollar | 7.3575 | |
GEL | Georgian Lari | 2.28778 | STD | São Tomé and Príncipe Dobra | 21893.55 | |
GGP | Guernsey Pound | 0.75217 | SVC | Salvadoran Colón | 8.736493 | |
GHS | Ghanaian Cedi | 3.947823 | SYP | Syrian Pound | 214.546669 | |
GIP | Gibraltar Pound | 0.75217 | SZL | Swazi Lilangeni | 14.54066 | |
GMD | Gambian Dalasi | 42.59464 | THB | Thai Baht | 34.61965 | |
GNF | Guinean Franc | 9027.285 | TJS | Tajikistani Somoni | 7.869075 | |
GTQ | Guatemalan Quetzal | 7.543124 | TMT | Turkmenistani Manat | 3.4714 | |
GYD | Guyanaese Dollar | 204.695665 | TND | Tunisian Dinar | 2.205754 | |
HKD | Hong Kong Dollar | 7.755684 | TOP | Tongan Pa'anga | 2.2566 | |
HNL | Honduran Lempira | 22.86081 | TRY | Turkish Lira | 2.953563 | |
HRK | Croatian Kuna | 6.686188 | TTD | Trinidad and Tobago Dollar | 6.688059 | |
HTG | Haitian Gourde | 64.840313 | TWD | New Taiwan Dollar | 31.66003 | |
HUF | Hungarian Forint | 277.678398 | TZS | Tanzanian Shilling | 2182.016667 | |
IDR | Indonesian Rupiah | 13242.75 | UAH | Ukrainian Hryvnia | 26.6502 | |
ILS | Israeli New Sheqel | 3.762393 | UGX | Ugandan Shilling | 3369.463333 | |
IMP | Manx pound | 0.75217 | USD | United States Dollar | 1 | |
INR | Indian Rupee | 66.70947 | UYU | Uruguayan Peso | 28.56358 | |
IQD | Iraqi Dinar | 1167.1167 | UZS | Uzbekistan Som | 2988.825 | |
IRR | Iranian Rial | 30085 | VEF | Venezuelan Bolívar Fuerte | 9.9765 | |
ISK | Icelandic Króna | 115.812 | VND | Vietnamese Dong | 22269.716667 | |
JEP | Jersey Pound | 0.75217 | VUV | Vanuatu Vatu | 106.65 | |
JMD | Jamaican Dollar | 127.097801 | WST | Samoan Tala | 2.53 | |
JOD | Jordanian Dinar | 0.708212 | XAF | CFA Franc (BEAC) | 587.135376 | |
JPY | Japanese Yen | 103.8626 | XAG | Troy Ounce of Silver | 0.05224435 | |
KES | Kenyan Shilling | 101.20079 | XAU | Troy Ounce of Gold | 0.00075363 | |
KGS | Kyrgystani Som | 69.035602 | XCD | East Caribbean Dollar | 2.69902 | |
KHR | Cambodian Riel | 4071.319976 | XDR | Special Drawing Rights | 0.715776 | |
KMF | Comorian Franc | 441.025002 | XOF | CFA Franc (BCEAO) | 586.874578 | |
KPW | North Korean Won | 900.09 | XPD | Troy Ounce of Palladium | 0.001488 | |
KRW | South Korean Won | 1115.85335 | XPF | CFP Franc | 106.536751 | |
KWD | Kuwaiti Dinar | 0.301714 | XPT | Troy Ounce of Platinum | 0.000882 | |
KYD | Cayman Islands Dollar | 0.823733 | YER | Yemeni Rial | 250.037999 | |
KZT | Kazakhstani Tenge | 341.041 | ZAR | South African Rand | 14.49439 | |
LAK | Laotian Kip | 8072.985 | ZMK | Zambian Kwacha (pre-2013) | 5253.075255 | |
LBP | Lebanese Pound | 1507.2 | ZMW | Zambian Kwacha | 9.703948 | |
LKR | Sri Lankan Rupee | 145.3018 | ZWL | Zimbabwean Dollar | 322.322775 |
Note however, that you should not use this table in any of the functions
that you write in a1.py
. The table above is for testing your
functions; not for writing them. There is no reason for you to waste your
time hard-coding in all of the currencies listed in this table into your
program, since the web service you will contact already knows them all anyway.
One of the most important outcomes of this assignment is that you understand the importance of testing. This assignment will follow an iterative development cycle. That means you will write a few functions, then fully test them before you write any more. This process makes it easier to find bugs; you know that any bugs must have been part of the work you did since the last test.
In this section we help you get started with this process. We also provide an overview of the rest of the assignment.
To do this assignment, Python must be set up properly. If you have not already done this, follow the installation instructions to set it up on your computer. Alternatively, you can just work in the ACCEL lab.
You should also create a folder on your hard drive that is dedicated to this assignment and this assignment only. Every time that you work on a new assignment, we want you to make a new folder, to keep things organized and avoid problems with naming collisions. Make sure that the command shell and Komodo Edit are both open in the current folder before you start.
a1
In your newly created directory, you should create the module a1
(with file name a1.py
). This will be the main module for this assignment.
Following the
style guidelines, the first
three lines of this file should be single-line comments with (1) the module name, (2) the
name and netid of the authors, and (3) the date the file was last editted. Immediately
after this, add the following docstring:
"""Module for currency exchange This module provides several string parsing functions to implement a simple currency exchange routine using an online currency service. The primary function in this module is exchange."""
This docstring is the module specification. We recommend that you cut-and-paste the docstring into a1. For now, we want to expose you to specifications, not have you write them on your own.
a1test
Iterative development hinges on proper unit testing, which was covered in
lecture
and lab. In the same folder
as a1.py
, create the module a1test
(with file name a1test.py
). This will be the unit test for the
a1
module.
As with a1.py
, the first three lines of this file should be single-line
comments with (1) the module name, (2) your name and netid, and (3) the date the file
was last editted. Immediately after this, add the following Python code:
"""Unit test for module a1
When run as a script, this module invokes several procedures that
test the various functions in the module a1."""
import cornelltest
import a1
Add four procedure stubs to this assignment: testA
, testB
,
testC
, testD
. Remember that a procedure stub should have the
keyword pass
(indented) after the header, but nothing else. We will add
our test cases to these procedures later.
These procedures will eventually contain your unit tests, which we talked about in Lecture 6. If you are curious about how they are supposed to work, look at the example test2.py in that lecture.
Finally at the end of a1test
, you will need to add code to active
the test procedures. Add these lines:
testA()
testB()
testC()
testD()
print "Module a1 passed all tests"
Again, see the lecture slides
for an explanation of why you are doing this. The script code will call your four test
procedures, which are (currently) empty. If everything is working, then the module print
out the message
"Module a1 passed all tests"
Try this out.
The rest of the assignment is broken into four parts (listed as Parts A, B, C, and D). In each part, do the following:
We will give you the header to write. We will also give you a detailed docstring specification for the function. You should copy-and-paste the specification into the function body, indented.
Yes, this means you are writing tests before writing the function bodies. We talked about this in lecture.
Unless otherwise instructed, each test case should be a call to an assert function in cornelltest. Furthermore, your tests should be representative. While we talked about this in class, you might be a little unsure of what we are asking for here. If so, you might want to work on the optional exercises in lab 4 with a consultant before going any further.
Make sure that the function satisify the specifications exactly. If the specification says to return something, you need a return statement. Make sure that the value returned is of the correct type.
If errors are found, fix them and re-test. Keep doing this until no more errors are found.
The descriptions that we provide in each part below represent the level of completeness and precision we are looking for in your docstring comments. In fact, it is best to copy-and-paste these descriptions to create the first draft of your docstring comments. If you do not cut and paste, please adhere to the conventions we use, such as using a single line, followed by a blank line and a more descriptive paragraph, or by using "Returns: ..." for fruitful-functions. Using a consistent set of good conventions in this class will help us all.
If you want to see if your specifications are written correctly, start an interactive Python shell and type
This should list all the functions with their specifications.>>> import a1 >>> help(a1)
A large part of this assignment is breaking up a JSON string. Conceptuually, you want to separate the currency amount from the currency name. For example, if we are given the string
"0.8963 Euros"Then we want to break it up into "0.8963" and "Euros".
This is the motivation for the two functions below. The implementation of these functions should be relatively simple. We were able to implement them both in one or two lines.
Returns: Substring of s; up to, but not including, the first space
Parameter s: the string to slice
Precondition: s has at least one space in it
Returns: Substring of s after the first space
Parameter s: the string to slice
Precondition: s has at least one space in it
Implement these functions according to their specification, as described in the Instructions for the Remainder of the Assignment. In other words,
To test the functions, you should make use of assert_equals in the module cornelltest to compare the result of each functions with the string that you expect to get back. Our solution has four test cases for each of the two functions above. When you think about what test cases you want to include, consider the following:
Finally, do not forget to add a specification to testA(). Just because it is used for testing does not mean that it should not be properly specified.
All of the responses to a currency query, whether valid or invalid, contain the keywords "from" and "to". If it is a valid currency query, then the answer is in quotes after the keyword "to". If it is invalid, then the quotes after "to" are empty. Hence the next step is to extract the information in quotes after these keywords.
While working on each of the functions below, remember to write the test cases in
at1test.py
before implementing the body. All test cases in this section
go in the procedure testB(), which you should remember to specify. You
should thoroughly test each function before implementing the next one.
Returns: The first substring of s between two (double) quote characters
A quote character is one that is inside a string, not one that delimits it. We typically use single quotes (') to delimit a string if want to use a double quote character (") inside of it.
Example: If s is 'A "B C" D'
, this function returns 'B C'
Example: If s is 'A "B C" D "E F" G'
, this function still returns
'B C'
because it only picks the first such substring.
Parameter s: a string to search
Precondition: s is a string with at least two (double) quote characters inside.
You should have completed the function above in lab 3. Because this function is technically part of the lab, and not the assignment, you may talk to students other than your partner about it (collaboration is always allowed on labs). This is the only function for which this is allowed. The rest of the functions are part of the assignment, so you may only collaborate with your partner.
Once you have this function completed, you should move on to the following functions.
Returns: The FROM value in the response to a currency query.
Given a JSON response to a currency query, this returns the string inside double quotes (") immediately following the keyword "from". For example, if the JSON is
'{"from":"2 United States Dollars","to":"1.825936 Euros","success":true,"error":""}'
then this function returns '2 United States Dollars'
(not '"2 United States Dollars"'
). It returns
the empty string if the JSON is the result of on invalid query.
Parameter json: a json string to parse
Precondition: json is the response to a currency query
Returns: The TO value in the response to a currency query.
Given a JSON response to a currency query, this returns the string inside double quotes (") immediately following the keyword "to". For example, if the JSON is
'{"from":"2 United States Dollars","to":"1.825936 Euros","success":true,"error":""}'
then this function returns '1.825936 Euros'
(not '"1.825936 Euros"'
). It returns
the empty string if the JSON is the result of on invalid query.
Parameter json: a json string to parse
Precondition: json is the response to a currency query
Returns: True if the query has an error; False otherwise.
Given a JSON response to a currency query, this returns the opposite of the value following the keyword "success". For example, if the JSON is
'{"from":"","to":"","success":false,"error":"Source currency code is invalid."}'then the query is not valid, so this function returns True (It does NOT return the message
'Source currency code is invalid'
).
Parameter json: a json string to parse
Precondition: json is the response to a currency query
As always, write your unit tests before implementing the two functions. Look carefully at the specifications. You only need to test valid JSON queries. To get some JSON responses for testing, enter a query URL into the web service and copy the result into a test case.
You should not need a conditional statement to implement these functions; simply find
the position of the appropriate keyword and extract the value
in quotes immediately after it. Your implementation must make use of the
find() or index()
string methods, plus the helper function first_inside_quotes()
.
Now it is time to interact with the web service. In this part, you will implement a single function. The test cases for this function should go in procedure testC() in a1test.py. Do not forget to specify testC() properly.
def currency_response(currency_from, currency_to, amount_from):
"""Returns: a JSON string that is a response to a currency query.
A currency query converts amount_from money in currency currency_from
to the currency currency_to. The response should be a string of the form
'{"from":"<old-amt>","to":"<new-amt>","success":true, "error":""}'
where the values old-amount and new-amount contain the value and name
for the original and new currencies. If the query is invalid, both
old-amount and new-amount will be empty, while "success" will be followed
by the value false.
Parameter currency_from: the currency on hand
Precondition: currency_from is a string
Parameter currency_to: the currency to convert to
Precondition: currency_to is a string
Parameter amount_from: amount of currency to convert
Precondition: amount_from is a float"""
While this function sounds complicated, it is not as bad as you think it is.
You need to use the
urlopen
function from the module urllib2
. This function takes
a string that represents a URL and returns an object that represents the web page for
that url. This object has the following methods:
Method | Specification |
---|---|
geturl() | Returns: The URL address of this web page as a string. |
read() | Returns: The contents of this web page as a string. |
Using one or both of these methods (you might not need them both) is enough to implement the function above.
You need to ensure that the function returns exactly the right JSON string for the value given. The best way to test this is to use a web browser to manually get the right JSON answer. For example, one test case can be constructed by seeing the result of going to the URL
http://cs1110.cs.cornell.edu/2016fa/a1server.php?from=USD&to=EUR&amt=2.5
Copy the value from this web page into a test case in testC()
.
Then check that the function returns the same JSON string. Remember to be thorough
with your choice of test cases; one is not enough.
Important: Fetching a web page takes time, especially if too many people are trying to do so simultaneously. You should give each call to this function at least 5-10 seconds to complete before restarting any tests.
We are now ready for the final part of the assignment. Implement the following specifications, again using our test-case-before-function-body approach. The test cases should go in procedure testD() in a1test, which you should properly specify. You may wish to use assert_true() instead of assert_equals() in some of your test cases. There is also a case in which you will want to use assert_floats_equal(). If you are confused by this, you can get help by working through the optional exercises in lab 4 with a consultant.
def iscurrency(currency):
"""Returns: True if currency is a valid (3 letter code for a) currency.
It returns False otherwise.
Parameter currency: the currency code to verify
Precondition: currency is a string."""
In implementing iscurrency()
, you should not use the
table of currencies. That would make a very large
function with a lot of if-statements. You are not allowed if-statements
in this lab. Instead, you must use the functions currency_response
and has_error
as helper functions.
def exchange(currency_from, currency_to, amount_from):
"""Returns: amount of currency received in the given exchange.
In this exchange, the user is changing amount_from money in
currency currency_from to the currency currency_to. The value
returned represents the amount in currency currency_to.
The value returned has type float.
Parameter currency_from: the currency on hand
Precondition: currency_from is a string for a valid currency code
Parameter currency_to: the currency to convert to
Precondition: currency_to is a string for a valid currency code
Parameter amount_from: amount of currency to convert
Precondition: amount_from is a float"""
In the case of iscurrency()
, you will find the
exchange table useful in determining correct answers for
your test cases. While it is not okay to use the table in the body of
iscurrency()
itself, it is okay to use the table to to decide on some
test cases.
You may also use the table to craft some test cases for the function
exchange
. However, you might find it easier to use a currency
query URL to look up the correct answer, and then paste the answer into your
test case.
A bigger issue with testing exchange
is that problem that we saw in class:
real numbers cannot be represented exactly. This creates problems when you try to test
equality between floats. To solve this problem, cornelltest provides a function
called assert_floats_equal(). You should use this function to test exchange()
instead of assert_equals(). There is an example of this in the optional
exercises of
lab 4.
Finally, bear in mind that, like currency_response
, these functions
connect to the web service, and so are not instantaneous. In our solution,
with complete test procedures for everything, it can take up to 2 seconds to
run the unit test on campus. This will be a bit slower if you are working
closer to the deadline.
Once you have everything working you should go back and make sure that your program meets the class coding conventions, including the following:
One of the things that you may have the biggest difficulty with is breaking up long lines. First, you may not be aware when your lines are too long. There is an easy way to test. In Komodo Edit choose Edit > Preferences > Editor > Smart Edition. Select the checkbox that says Draw the edge line column.
As for breaking up long lines, there are two solutions. First, Python allows you to "hit Return" within any expression inside of parentheses. So if you are adding together several expressions together, like
a = 'Hello ' + name + ', it is good to meet you'
you can break it up over several lines, using parentheses, as follows:
a = ('Hello ' + name + ', it is good to meet you')
Another solution is to use the backslash symbol \. Remember that this is the escape character for making special characters in strings. It also has a special effect outside of a string. If you type this symbol, immediately followed by a return, then Python will know to continue to the next line. So you can rewrite the addition above as
a = 'Hello ' + name + \ ', it is good to meet you'
Upload the files a1.py
and a1test.py
to CMS by
the due date: Sunday, September 18th at 11:59 pm.
Do not submit any files with the extension/suffix .pyc
. It will
help to set the preferences in your operating system so that extensions always appear.
Check the CMS daily until you get feedback from a grader. Make sure your CMS notifications for CS 1110 are set so that you are sent an email when one of your grades is changed. To find the feedback, click on the Assignment 1 link in CMS. On the page you are brought to, click on the red word "show" in the line "Grading Comments & Requests (show)." You can contact your grader if you have questions about their feedback; you can see their netid in the place you can see their feedback.
Within 24 hours, do RRRRR: Read the feedback, Revise your program accordingly, Resubmit, and Request a Regrade using the CMS. If you do not request a regrade, we have no simple way of knowing that you have resubmitted.
This whole process, starting from first submission on Sunday, September 18th, continues until you submit a solution that demonstrates complete mastery; in some cases this may require multiple additional resubmits by you. You need to complete this process within one week. You need to have submitted a final, correct version by Sunday, September 25th, which means you will probably want to have re-submitted at least once before then.
In addition to turning in the assignment, we ask that you complete the new survey posted in CMS. These assignments are still rather new(ish), and we would like some understanding of how long you spent on the assignment, your impression of the difficulty, and what could be done to improve it.
Please try to complete the survey within a day of turning in this assignment. Remember that participation in surveys compromise 1% of your final grade. We also ask that you be honest in your answers.
This section is not part of the assignment. It is optional. Furthermore, do not make the changes in this section to the file that you submit for grading. It will be sent back to you to fix.
This assignment was first designed back in 2012, to take advantage of a service called iGoogle. iGoogle was a JSON service provided by Google (hence the name) which supported simple Python programs. It was intended for any data that might be changing often, such as currency exchange rates, weather data, or similar types of things. Unfortunately, Google discontinued the service in November 2013, two months after we ran the assignment for a second time.
This meant that we could still simulate a fake currency exchange service, but we no longer had a real-world example to show off the power of this assignment. Most replacements to iGoogle typically charge for their service (because they are used by currency traders), and we could not justify the subscription cost for a single assignment.
Fortunately, there is a brand new service called Open Exchange Rates. This service still charges, but it is free if you only need a new currency value once an hour. This is a pretty good compromise, because that is frequent enough for anyone who is not a currency trader.
The data from Open Exchange Rates is not in a format usable by this assignment. However, it does allow your instructor to turn our fake currency service into a real currency service. We are actually running two currency servers in this class. In the web service instructions we told you to use the URL prefix
http://cs1110.cs.cornell.edu/2016fa/a1server.php?If you change that prefix to
http://cs1110.cs.cornell.edu/2016fa/exchange.php?you will get our real server instead. Try that out on converting dollars to Euros (pick small values for now).
The server updates once an hour at 30 minutes after the hour. To see this in action, run a query just before this time, at say 8:28. Wait 5 minutes and run the same query again. See how it changes? This is one of the reasons we did not use the real service in development; it is too hard to test against. In fact, even professional software engineers would do what we did: write a program against an unchanging exchange service before deploying it against the real thing.
We promise to keep the real server running for at least the next year, should you wish to show this off to other people.