Some time ago, I wrote a web-based calendar application in PHP, one of my favourite programming languages. This tool would produce a HTML tabular calendar for a four week period, Monday to Sunday, in which the current date (or a user-specified date) fell in the second week (so you’re looking at this week, last week, and two weeks in the future). The user-specified date, for various reasons, would be provided as the number of seconds since the epoch (1970). In addition, the user must be able to flick forwards and backwards through the calendar, “shifting” by one or four weeks each time.
Part of this algorithm, of course, was responsible for finding the timestamp (seconds since the epoch) of the beginning of “a week last Monday”, GMT. It went something like this (pseudocode):
1. Get a handle on the beginning of "today" with [specified time] modulus [number of seconds in day]
2. Go back in time a week by deducting [number of seconds in day] multiplied by [number of days in week] (you can see I'm a real programmer, because I set "number of days in week"
as a constant, in case it ever gets changed)
3. Find the previous Monday by determining what day of the week this date is on (clever functions in PHP do this for me), then take
[number of seconds in day] multiplied by [number of days after Monday we are] from this to get "a week last Monday"
4. Jump forwards or backwards a number of weeks specified by the user, if necessary. Easy.
5. Of course, this isn't perfect, because this "shift backwards a week and a few days" might have put us in to "last month", in which case the calendar needs to know to deduct one month
and add [number of days in last month]
6. And if we just went "back in time" beyond January, we also need to deduct a year and add 11 months. Joy.
So; not the nicest bit of code in the world.
I’ve recently been learning to program in Ruby On Rails. Ruby is a comparatively young language which has become quite popular in Japan but has only had reasonable amounts of Westernised documentation for the last four years or so. I started looking into it early this year after reading an article that compared it to Python. Rails is a web application development framework that sits on top of Ruby and promises to be “quick and structured”, becoming the “best of both worlds” between web engineering in PHP (quick and sloppy) and in Java (slow and structured). Ruby is a properly object-oriented language – even your literals are objects – and Rails takes full advantage of this.
For example, here’s my interpretation in Rails of the same bit of code as above:
@week_last_monday = 7.days.ago.gmtime.monday + params[:weeks].to_i.weeks
An explanation:
- @week_last_monday is just a variable in which I’m keeping the result of my operation.
- 7.days might fool you. Yes, what I’m doing there is instantiating an Integer (7, actually a Fixint, but who cares), then calling the “days” function on it, which returns me an instance of Time which represents 7 days of time.
- Calling the ago method on my Time object, which returns me another Time object, this time one which is equal to Time.now (the time right now) minus the amount of Time I already had (7 days). Basically, I now have a handle on “7 days ago”.
- The only thing PHP had up on me here is that it’s gmdate() function had ensured I already had my date/time in GMT; here, I have to explicitly call gmtime to do the same thing.
- And then I simply call monday on my resulting Time object to get a handle on the beginning of the previous Monday. That simple. 24 characters of fun.
- + params[:weeks].to_i.weeks simply increments (or decrements) the Time I have by a number of weeks specified by the user (params[:weeks] gets the number of weeks specified, to_i converts it to an integer, and weeks, like days, creates a Time object from this. In Ruby, object definitions can even override operators like +, -, <, >, etc., as if they were methods (because they are), and so the author of the Time class made it simple to perform arithmetic upon times and dates.
This was the very point at which I feel in love with Ruby on Rails.
![Ruby Active Record Associations [PNG]](http://www.loudthinking.com/lt-files/ar_associations.png){kind=link}
Forcing people to have deliveries sent to their registered address cuts down on card fraud, which is moderately freqent at mail order computer hardware stores on account of the high value, discreetness, and availability of the goods. It’s not possible to accurately perform such checks on credit cards, but it’s easy to with debit cards.
Many banks give special dispensation on their student accounts; allowing them to – for example – submit two addresses which they will automatically switch between throughout the year – or allow two registered addresses to function for card checks (while still delivering the statements to one). Ask your bank if they can do this, and, if they can’t, write a letter to inform them that there are banks that can. If you’re not willing to let your feet do the talking, there’s no way to let these large organisations listen to you.
There’s no reason not to own a credit card unless you feel you cannot trust yourself to do so – or the banks won’t give you one! For many such cards, there is no interest if you pay them off immediately each month (which can be automated thanks to wonderful schemes like Direct Debit): this increases the flexibility of your purchasing power (particularly when purchasing from overseas) without costing you a penny. On a side note, owning one that you only ever use in this fashion increases your credit rating (which is checked when buying a contract mobile phone, getting a mortgage, applying for credit on a car, or whatever). Just for examples’ sake; if you owned an unused credit card, you could have ordered these computer parts and – odds are – immediately transferred the money from the bank account to the card, thereby giving you the bits sooner.
All of that said, I think I’ve quite aptly (and almost entirely) undermined the sense in preventing expensive goods being delivered only to the registered cardholder’s address, because as we’ve just seen there’s always a way to circumvent such checks by routing the money other ways: this leaves a longer paper-trail (banks and credit companies are, by law, required to keep better records for longer than companies that happen to process card transactions), but is otherwise a sensible way to commit fraud without triggering the little alarm bells that debit cards have hanging from them. So yeah; perhaps Scan should be a little less draconian.
Now Chip-And-PIN in the UK: there’s a flawed, insecure, badly-implemented system.