Dolfin Blog

September 11th 2024 (a0.4.0)

Fixed date comparison code. Hopefully there aren't any issues, might take some time to find some bugs but so far it appears the date comparison works successfully.

September 10th 2024

Subscriptions are almost implemented. Basically if any subscription option other than "None" is chosen, a subscription is created from the transaction and the next renewal date is calculated.Then every time the update function is called, each subscription renewal date is checked against the current date, and if the renewal date is older than the current date, pay the cost of the subscription and update the renewal date.

I just need to do some testing with it and it should be good to go. No input sanitisation yet though, though that's going to be my next task.

September 9th 2024 (a0.3.5)

Huzzah, after a bit of research I have discovered that dividing an integer by 100 is pretty much safe for any sane value used in this program. This means I can multiply 0.6 as 60, and divide the resulting number by 100 without issue. Might need to dive into some research on floats to feel confortable doing this, but for now, what the heck. I just want to move onto actually implementing features already.

Also changed the income system so that if a single account is specified, it applies the full amount without dividing it up.

September 7th 2024 (a0.3.4)

My mistake yesterday was that I assumed 100 was stored as 100 rather than 10000, so my method would not work without dividing 10000 by 100. Code has been refactored a bit though, so I'll push it. Not much else has been done today.

September 6th 2024

Decided to start tackling the issue of floating-point arithmatic. As computers cannot store floating point values with infinite precision, there will almost always be a degree of error in the result of any operation involving them. When dealing with currency, we can't afford to ignore these kinds of errors, so we must rely on fixed-point arithmatic. So far, I have dealt with floats by instead storing fractional numbers as integers with a fixed number of decimal places. Addition and subtraction operations have been easy to accomplish, but when an income is provided across each account, it must be split up according to each account's percentFromIncome value, which is stored as a float. For example, an income of 100 provided to an account with a percentFromIncome value of 0.6 will require a calculation of 100 * 0.6.

As I type this out, I've worked out the solution. I instead need to represent 0.60 as an integer of 60, and instead calculate using fixed-point arithmatic 100 * 60. This returns 6000, and reintroducing the decimal point gives the actual value of 60.00

It's late, so I'll implement this tomorrow. I also need to generalise the decimal code from yesterday into a function.

September 5th 2024 (a0.3.3)

The decimal bug has been resolved by multiplying the number depending on how many decimal places the number has. When working this out, a pattern seemed to emerge as follows:

From this, it can be observed that the value of multiplication decreases by a factor of 10 as the number of decimal places increases, as shown by the functon 10^(2-n), n being the number of decimal places. For values of n > 2, an alert is thrown to warn the user of an invalid input and the entry is discarded. Although this is a fairly neat equation, I have decided to go with a switch statement for the time being as I am assuming the speed of a few variable conparisons to be faster than using the Math.pow() method. Decimal currency values can now be stored safely as integers.

It should be noted that all values featuring a decimal point are strings; all fractional values are stored as full integers, with the last two units acting as the decimal component.

September 4th 2024 (a0.3.2)

I have applied the currency value system to the transaction objects and income input, so fractional values can be represented. However, numbers with only a tenth position, such as 12.8 or 56.9, are bugged and will as 1.28 and 5.69 respectively. I will need to code a function that reads the number of decimal places in the number, and then multiply it by 10. Shouldn't be too hard, but it will have to be done tomorrow. I'll push this update anyway, as I haven't pushed to github for 3 days now.

Should also note that the percentFromIncome values are introducing floating point arithmetic into the code, which needs to be dealt with. As of now I don't have a plan. Something else to deal with tomorrow.

September 2nd 2024

Spent the evening trying to figure out how to represent a currency value in code. The clear solution is to use an integer, counting pennies rather than pounds, as the use of floating points is out of the question due to rounding errors. But when it comes to displaying the currency to the user I need to insert the decimal point, and this isn't like C where I can just modify the char array and shove it in there. There's a way to splice a value into an array in JS, but strings are immutable so I'm going to have to figure out some other method.

To solve this problem, I simply sliced the string bewtween its significant and decimal figures and then concatenated them together with a decimal point inbetween. There is an object called 'Intl' that could help me out here, but I won't delve too deep into it just yet. Are we still allowed to use the word "delve"?

This introduces a problem for whole numbers, as a value of 123456 will be displayed as 1234.56 using this method. The solution I found for this was to simply check for a decimal point in the number string and if one isn't present, multiply the number by 100. So entering a value of 80.86 would hold it internally as 8086, but entering 8421 would hold it internally as 842100.

The code currently does not handle numbers with a single decimal-place, and only works with the account input. Trying to apply income to the balances causes things I cannot explain, so hopefully I can fix things up tomorrow. Object ID system is also bugged. Yippee.

September 1st 2024 (a0.3.1)

Going to spend today learning git, as I am going to begin using version control from here on out.

The github repository can be found here

Changed the load/save buttons back to hyperlinks as buttons cannot be used as links.

August 31st 2024 (a0.3.0)

Accounts can now be removed, as can any transaction featured in the transactions table. Some refactoring has also been done with the HTML structure, involving the removal of some unnecessary div elements. The mobile formatting issue continues to elude me. I'm also starting to wonder if I need every <div> to be a box element... by removing the classes from all of the field elements and freeing the field headers from their <div> constraints, I managed to slim down some bloat on both the page and the HTML file. The mobile formatting issue continued to persist however, so I have decided to slim the grid-template-columns down to two colums for the overview tables and a single column for each of the forms. I don't like it, but once I introduce the menu system it hopefully shouldn't matter, and anything looks better without CSS elements trying to escape the screen.

Styled the buttons to give them a nice rounded look. I think this is as good as the HTML structure is going to get. The save and load buttons are quite garish though, and are overlapping some of the other elements, so I have moved them into the overview grid and downgraded them to standard buttons. I'll style them tomorrow.

On second thought, the new column view looks like $#!+.

August 30th 2024 (a0.2.0)

Transaction and subscription views have been incorporated into the overview window. The transaction table displays a table detailing the last 5 transactions, whereas the subscription table displays no data, as the subscription framework has not yet been implemented. This marks the completion of the overview framework.

The CSS is kinda broken on mobile, I should probably fix it sooner rather than later, but most of the work left to do is on the JavaScript side. I will probably set up a menu that switches between forms which may help decrease the box width, but I do want to figure out the underlying issue.

(Note: This page looks surprisingly okay without CSS.)

August 29th 2024 (a0.1.0)

I started learning Javascript and CSS 9 days ago, and I have already done a bunch of work over the last few days setting up the input fields and a local storage solution, though both are unfinished. The plan going forawrd will be to develop the app in four stages. I've included these stages above, under the todo list.

The framework for data entry is finished, so accounts can be created, account balances can be increased and transactions can be created to reduce the account balances. Subscriptions have no effect thus far, but they can be entered into the transaction list, which is all that matters for now. Of course I still need to create a system for account deletion, and it would probably be a good idea to ignore the income-distribution factors for each account when a single account is selected under the income form, but that's something to deal with tomorrow. Also, added "Input sanitisation" to the todo list.