EpiHandle's corner of the Internet

Weekly Vusfy update #10

May 26, 2024

Hello everyone,

How are you? As always, it is a pleasure to have you here.

Welcome to the 10th instalment of the Weekly Vusfy progress updates. I am pleased to say that this week’s update has more content than last week’s, so let’s get into it.

Dependency updates

A classic.

Fix some test failures relating to timezones

This is a weird one, and I still do not know why it is happening.

Some functionality in Vusfy depends on checking what time zone you are in. For example, when you are using the buttons to create a goal occurrence for today or yesterday. The rationale behind this is to make sure that what today or yesterday is what you expect, taking into account your time zone. If the time zone you set in Vusfy is Copenhagen, but you are now vacationing in Los Angeles, your idea of today and Vusfy’s may differ, depending on when in the day you press the button.

Some tests (not all) that deal with time zones started failing because, all of a sudden, the browser for the end to end tests began using a different time zone. I dug and dug, but the cause still eludes me. However, it is not all doom and gloom.

I have tested on my local development environment, and on production (Vusfy’s website). I am unable to replicate the issue, and nothing is broken, so I am confident in saying it is an issue limited to the testing environment. While less than ideal, it is better than having this happen on Vusfy.

Since I could not get to the bottom of this, I did what you should not do. I updated the time zone in the tests to match the one used by the browser the end to end tests spawn.

I am coming back to this issue, because I refuse to let it get the best of me. At the same time, it has all the hallmarks of a massive time sink, and I had stuff I was working on that I wanted to release this week.

So, I compromised. Software development is nothing more than treading the fine line between an acceptable and unacceptable compromise.

Improve tests for creating an event or goal without knowing when they happened

While working on improving the pages for goals and events, I noticed that a couple of tests were not testing what they were supposed to.

When you create an event or a goal, you can create them without setting when they happened. The tests for this were not doing this, because they were setting when they happened. Now, they do not set it, thus doing their actual job.

I would like to point out that the features these tests cover work as intended. I am pleased to say their tests now work as intended too :)

Remove collapsible elements when viewing a goal

Before this change, when you visited any of your goals, you would see 4 collapsible elements. These 4 elements contained:

  1. The details for the goal;
  2. The occurrences for the goal;
  3. The rewards for the goal;
  4. The conditions for the goal.

Now, those collapsible elements are gone. Points #2, #3, and #4 are on their own pages, with point #1 occupying the first page you land on when viewing your goal. To navigate between them, there is a Contents section at the top of each of those 4 pages.

I made this change because those collapsible elements were something I thought would work, but they did not. After using them for some time, I would rather have separate pages than opening and closing elements all the time. It is just easier, especially if there is a long list inside any of them. I could have introduced pagination, but the amount of complexity it would have introduced was not worth it. The solution I chose is easier to use and more maintainable, so win-win.

Remove collapsible elements when viewing an event

This is similar to the previous section.

Before this change, when you visited any of your events, you would see 4 collapsible elements. These 4 elements contained:

  1. The details for the event;
  2. The occurrences for the event;
  3. The rewards for the event;
  4. The goals for the event.

Now, those collapsible elements are gone. Points #2, #3, and #4 are on their own pages, with point #1 occupying the first page you land on when viewing your event. To navigate between them, there is a Contents section at the top of each of those 4 pages.

I made this change because those collapsible elements were something I thought would work, but they did not. After using them for some time, I would rather have separate pages than opening and closing elements all the time. It is just easier, especially if there is a long list inside any of them. I could have introduced pagination, but the amount of complexity it would have introduced was not worth it. The solution I chose is easier to use and more maintainable, so win-win.

Remove collapsible element when viewing a reward

This is similar to the previous 2 section.

Before this change, when you visited any of your rewards, you would see 1 elements you could click on to open and close: the goals that had the reward.

Now, that collapsible element is gone. The goals are on their own separate page, and the reward’s details are on the page you land on when viewing your reward. To navigate between them, there is a Contents section at the top of each of those 2 pages.

I made this change because those collapsible elements were something I thought would work, but they did not. After using them for some time, I would rather have separate pages than opening and closing elements all the time. It is just easier, especially if there is a long list inside any of them. I could have introduced pagination, but the amount of complexity it would have introduced was not worth it. The solution I chose is easier to use and more maintainable, so win-win.

Conclusion

Thank you for your time, and until we meet again, take care of yourselves.

Cheers,
EpiHandle