Eric Murano

I made the tag line of my blog “Photography, Application Development and Falafel” because I wanted to talk about taking photos, programming and losing weight.  I have not talked about losing weight yet and since I’m losing a bunch of weight now then it’s appropriate for a post on the subject.

I chose ‘Falafel’ as the word that represents losing weight because of my partial Lebanese ancestry but also because when I have a kebab I always get the falafel kebab with tabouli.  No cheese, no crazy three animal meat etc.

But I digress …

My strategy for losing weight is portion and calorie control.  I realised not too long ago that the amount of food I was eating was the main cause of my weight gain.  Don’t get me wrong!  What I was eating was also a problem.  Lots of ‘fast food’ that not only had plenty of calories but also full of bad nutrients that caused non-weight related health issues.

I’d always get the large size of anything.  I’d finished my friends’ meals when they were done with it.  I’d order an extra burger along with the large meal deal.  I’d have second and third servings.  I’d stuff myself to the point of feeling bloated and awful yet still trying to cram more food in.

The first glimpse of the truth about my overeating was when I read the nutrition information on a box of cereal.  I never measured out my cereal before; I just dumped how much cereal I wanted into the bowl.  I’d get five breakfasts out of a box of cereal and usually bowl number five was small because the first four had been so large.  When I saw that the box should contain 17 servings I was shocked and thought “They’re out of their minds if they expect me to eat such a small amount of cereal for breakfast!”

It took me years of denial and subtle comments from friends about the volume of food I eat to finally accept that the amount I eat is the most significant factor to my weight.  The final straw on my denial’s camel’s back was when I listened to a lecture about physics that was designed to be taught to lawyers and political science students.  It was a brilliant course because it taught people that weren’t into science the basics of physics and energy as a general subject.  The lecturer said that the course was designed to teach the country’s (USA) future leaders enough to help them make good decisions.

The lecturer talked about how energy works and how it’s stored.  There was talk about petroleum and nuclear power and how energy affects politics.

In one of the lectures he talked about energy used by organisms, particularly human beings.  He talked about the fact that it’s incredibly easy to eat a lot of calories yet to work it off takes much more time than it did to eat that food.  The energy expelled while doing one hour of exercise can be completely eaten back in 5 minutes if you eat something with that much energy stored in it.  He even said that the exercise machines in the gym over report the calories burned because obviously people want to use the machine that burns the most so it’s even easier than you think to eat up to and beyond the calories burned in the gym.

At the end of it he simply said “If you want to lose weight, eat less calories”.

Now I realise that it’s an oversimplification and that exercise is very important but there’s a very important message here. No matter how well you do in the gym if you do not watch what you eat you can easily negate all that hard work.  Especially with the number of calories I was eating.

I’ve been going to the gym on and off for nearly ten years now and I’m still overweight.  Up until recently I didn’t take care of my diet and that’s why I hadn’t lost weight.  I did a lot of work in the gym but it meant nothing because I was over eating, undoing all of that good work.

Right now I record everything I eat into a calorie counting website.  When I started calorie counting I was shocked to see how many calories there are in certain foods.  Rice and bread were so shocking to me!  One cup of rice has 200 calories.  I used to have five cups of rice at least!

Two slices of bread have 180 calories.  Add 160 calories for the margarine and that Vegemite on toast becomes a near 350 calorie meal that doesn’t fill you up at all!

One large serve of chips from KFC or Red Rooster is over 500 calories.  I don’t even want to know how many calories there are in the burger!

Those numbers don’t seem that bad until you realise that someone my  weight should be eating maybe 2,500 calories a day.  Less than that to lose weight.

Five cups of rice with what ever curry or casserole on top of that would easily make a 2,000 calorie meal.  That leaves 500 calories for the rest of the day. Yipes!

When visiting my mum she’d make me chicken tortilla’s for dinner.  I’d eat 5 tortillas with marinated chicken, lettuce and grated cheese.  One tortilla bread is 200 calories.  So that’s already up to 1,000 calories just for the bread.  Add to that the chicken, the marinate and the cheese (the lettuce would be 20 calories total) and you’ve got yourself 3,000 calories easily.  If I didn’t eat anything else that day I’d still be over my daily energy intake.

These numbers are just mind blowing! No wonder I’m overweight!  My ideas on how much to eat were so way off.

I’m going to post about this more but I’ll end this post here.  I haven’t provided any concrete numbers but I hope I’ve conveyed the general gist of what I think the reason is for most people’s obesity.

So it’s been over 7 months since I posted on my blog.  I suppose there’s nothing wrong with that but I had intended to post regularly.  I definitely haven’t been “feeding the monster”, which is a blogging term that means you have to blog often to get a following.  I’m not really after a following; this is just a publicly available brain dump, really.

PayDay is on hold due to paid freelance work taking precedence over the unpaid passion project.  That’s ok, though.  The good thing about a passion project is you’re doing it for yourself and you’re not going to let down anyone if you need to shelve it for a while.

I was going to post about currencies in PayDay and I started writing the article but I think I’ve overcooked the idea of currencies.  Now I don’t think I even need currencies in PayDay.  It’s meant to be a personal budgeting tool that gives you a heads up about recurring bills.  Not many people have recurring bills that are from another country.

Another thing I was missing was the idea that the act of converting currency and how it is done is tied very much to the situation.  Why are you converting the currency?  If it’s to see how much that Think Geek t-shirt will cost in AUD then you’re going to have to take that conversion with a grain of salt.  That AUD figure is just not going to be what you are going to pay for that t-shirt once the transaction is done.  The obvious reason is that the exchange rate changes all the time.  That’s obvious.  Another reason is that the financial institution that make the purchase through will charge you their own rate for the conversion.  If you get your conversion rates from xe.com I guarantee that the rate will be different to the one that your bank will use when they send the money to Think Geek.  Let’s not forget that some banks will also charge a conversion fee.

Sometimes you just need an approximate representation of that foreign currency in your local currency.  You know it’s not accurate but that’s ok, you just need to know a ball park  figure.  Then currency conversion is more about statistics; “on average how much AUD will x USD cost?”

For currencies to make sense in PayDay I would have had to add the concept of ‘approximate value’ into the model.  I think that’s a valid concept to have but I wouldn’t bake it in until a few version later.  I think, also, I’d have to have the approximate value feature done before I could think about having multiple currencies in PayDay.  I’d make it so that approximate values were applicable not only to currency conversion but to bills that you know might change in value over time, like Brisbane City public transport costs (grr!).

Anyway once I finish my current freelance work I’ll get back into PayDay.  I bought a MacBook Pro a few months ago so I’ll have to get PayDay up and running on that.  I want to keep it as a .Net project so I might have to install Windows 7 on the Mac or wait for MonoMac.  Mac Zealots please don’t write in abusing me  If it’s all too hard to get a working .Net environment running on my Mac I might change the the project’s technology stack but I’d really like to have a mixture of technologies i.e. a .Net backend and website with an iOs app that talks to the backend.  We’ll see.

This the first of many posts about the implementation of PayDay, the software that I’m writing to help me with my personal finances.  I’ve been working on the project for a couple of months and one of the first things that I worked on was frequencies for recurring income and expenses.

One of the fundamental concepts in PayDay is the idea of a recurring income or expense.  I need to represent, for example, a monthly income, a weekly train ticket or a fortnightly gym membership.  These bills or income occur every so often, but the every-so-often is different for each one.

Not only that but a recurring item (from now on whenever I say ‘item’ I mean income or expense) has its own start date.  Two monthly items, while they occur as often as each other, might start on different days of the month.  My car loan comes out on the 16th but I’m paid on the 14th, for example.  Also frequencies aren’t always as simple as daily, weekly or monthly because you might want to represent things like ‘every second Tuesday’ or ‘the 14th of the month unless it’s on a weekend then the last Friday before the 14th’.

To implement the functionality of frequencies I considered creating an enum (enumerated type) with all possible types of frequencies.  The problem with this approach is that there are an infinite number of possible frequencies that you can have for a recurring event.  Most things fit into the common frequencies like weekly and monthly, but there are other events whose occurrences have to be specifically determined.  Take, for example, the schedule for being paid monthly.  Most employers will pay on the 14th or 15th of the month except if that date occurs on a weekend or a Monday, in which case the employee will be paid on the Friday so that they have money for that weekend.

Now I can’t think up all possible types of frequencies, yet I want to be able to support new types of frequencies without too much modification.  I could, theoretically, make a frequency engine that you supply parameters and rules to define your frequency but that’s too much work for people who aren’t developers.  Imagine PayDay asking you to “define the parameters of the frequency of this expense” … yeah I wouldn’t use software that asked me to do that!

I need to implement a few common ones and get on with the rest of the application.  I do, though, want to be able to introduce new frequencies later on but also I’d like anyone that writes software that uses the PayDay library to be able to invent their own frequencies without having to touch the PayDay library’s source code.

To accommodate this I created an interface that any class that wants to offer frequency information needs to implement.  I called it ITimeFrequency and it had two methods to implement:

/// Given a date when the event happens,
/// return the date of the next occurrence
DateTime NextOccurence(DateTime occurrence);

/// Given a date when the event happens,
/// return the date of the previous occurrence
DateTime PreviousOccurence(DateTime occurrence);

I really wanted to keep the interface lean. There originally was another method in the interface that returns all the dates of occurrences between a start and end date, but all concrete classes implementing the interface would have the same code for that method I decided to put that method into a static class called TimeFrequency:

public static List<DateTime> OccurrencesInDateRange(
    ITimeFrequency freq,
    DateTime fromDate,
    DateTime toDate
)

So whenever you call TimeFrequency.OccurencesInDateRange(), it’s calling NextOccurence of the ITimeFrequency passed to it to figure out the dates of the occurrencies

I created concrete classes that implement the ITimeFrequency interface: daily, weekly, monthly, yearly and fortnightly.

The general idea with all this is that if you have an event that occurs regularly, you can figure out when that event occurs from when it started onwards. So if I have a weekly event that started on the 26th of July, 2010, I know that the next occurrence will be 2nd of August, 2010 and the next occurrence is the 9th of August and so on. The NextOccurrence() method defined in the ITimeFrequency interface is what calculates what the date of the next occurrence will be. Though the application will not try to calculate occurrences that occur too far into the future, it will calculate all occurrences that occur in the date range that the user is viewing.

After the ITimeFrequency interface and it’s concrete classes was written I hit a snag with the monthly frequency. The issue was that calendar months have different numbers of days, 28, 29, 30 and 31. If something starts on the 31st the next month, unless it’s August, will have less days in it and therefore the next occurrence needs to be the last day of the month; except when the subsequent occurrence is calculated it will not be on the 31st, it will be on either the 30th, 29th or 28th, depending on the month.

Here’s an example: I have a monthly event that starts on the 31st of August. The second occurrence will be the 30th of September. This is because the monthly frequency knows that there is no 31st of September so it chooses the 30th, which is September’s last day. The third occurrence is then calculated but because NextOccurrence() only goes off the date of the previous occurrence, 30th of September in this case, it doesn’t know that the event really should occur on the 31st of October and it erroneously chooses the 30th of October.

What ends up happening is the day the occurrences are meant to happen on eventually go to the 28th. Once the occurrences hit February on a non-leap year that’s it.

So the monthly frequency really needed to have an occurrence day.  The day of the month when an occurrence should happen if the month has that many days. If it doesn’t then the last day of the month is selected. The occurrence day is supplied in the constructor of the monthly frequency object.

Giving the month frequency an occurrence day introduced another issue. If you create a monthly frequency with an occurrence day, then you call it’s NextOccurrence() method with a date that has a day that is different to the monthly frequency’s occurrence day, the method not return a date that is one month after, it will return the next time the occurrence day occurs.

For example: I create a monthly frequency with an occurrence day of the 12th. I then call its NextOccurrence() method with a parameter of the 15th of July, the answer will not be the 15th of August, it will be the 12th of August. Now this is exactly how NextOccurrence() should work. It has given you the correct answer; the next occurrence of the 12th after the 15th of July is the 12th of August, but if I have a recurring item that starts on the 15th yet I’ve declared that it occurs on the 12th, I need a way to tell the user that the dates and frequency they’ve chosen are inconsistent.  To do this the code that calls NextOccurrence() needs to call another method that checks to see if the start date is counted as an occurrence.

/// Is the given date a valid occurrence
bool IsValidOccurence(DateTime occurrence)

Now it’s possible for the recurring item code to check to see if an item’s start date should be counted as an occurrence.

I’ve really tried to make the frequency code open for all kinds of frequencies. The only restriction I have is that the smallest unit of time frequencies can work with is a day. For this application I didn’t want to have sub-day frequencies like hourly and every-minute.

My next post about PayDay I’ll talk about how I’ve dealt with representing money.