[Day 8] Technical | Fixing Code Errors and Moving Ahead

[Day 8] Technical | Fixing Code Errors and Moving Ahead

Today we’re diving into considerations on how to handle global time and I’m sharing some lessons learned and progress. It’s another technical day to day, so if you’re on the lookout for business value, feel free to skip.


Who the Hell Invented Daylight Savings Time? Definitely Not a Coder.

We live in a globalised world and therefore, all of us on the internet are scattered all around the globe. While I like the concept of globalization in general, it brings a challenge with it. The current time is different for most of us. But timezones are alright. They’re the result of a natural fact and therefore there’s not much sense complaining about them. What makes the whole situation more difficult is the human invention of daylight savings time.


While the economic value of daylight savings is questionable, it also makes handing times and timezones much more difficult. Some countries have daylight savings time, some don’t. They work exactly the opposite way on the northern and southern hemisphere. In short: it’s a huge mess. Managing global time is not as easy as it sounds. To conquer the problem, I first had a solution in mind where I would calculate the local time of each user by his country setting in his profile.


WordPress doesn’t come with a localized user time functionality, and after briefly going through the amount of effort it would take to implement this and also remembering my 80/20 principle, I decided to go for a quick solution and focus my efforts somewhere else. What WordPress comes with is a function current_time to retrieve the current time in two formats: the local time (of the time zone of the WordPress installation) and the GMT. At the end, I decided not to give users the opportunity to store times for now (only dates). For system generated times like the time an application record was created, I’m saving the both time formats WordPress is providing. If you want more input on the time challenge and how to handle it in WordPress, there you go.


Handling User Roles

I definitely have to factor in a big block of time every day to solve a problem that pops up. I spent quite some time developing and refining the database interactions I mentioned in yesterday’s post. When quickly testing the functionality to create a new application record with a test user I created, I checked the database and saw… nothing.
A couple of tests later I figured out that the issue lies in the user role of a “normal” user. While I am developing I WordPress as an administrator, new users automatically get the “subscriber” role. So obviously so far, issues that users with these roles would encounter went unnoticed by me. For some reason the transmission to the database doesn’t work, when the logged in user is a subscriber. As soon as I promote him to administrator, shrugging works fine. This would of course be a showstopper for the project if I don’t manage to find a solution. So I’m putting in a few extra hours tonight to figure out what the problem is exactly and try to fix it. If someone experience with this situation or an idea what the issue could be, I’d be grateful for a hint.


Creating Automated Email Notifications

One of the functionalities of the first version of N-ter will be to notify users if an application deadline is approaching. For this we need to send out automated emails on a regular schedule. The way to achieve this is to set up a so-called cron job (I was still not able to determinewhether it stands for Command Run On Unix, or it’s just a derivation from Greek “chronos”, which means “time”. Probably both.)


This is a task you can set up to perform something regularly. It can either be done directly on the server (which is the more sustainable option) or do it right in WordPress with the help of a plugin. For now we’re going with option two. For this we need to install a new plugin called Crontrol. The plugin shows us all existing cron jobs on our WordPress installation and lets us modify and delete them or create new jobs.


The new cron job we need triggers a piece of code which is stored in our functions.php. This code is basically just finding all applications in the database, who are close to the application deadline and sending out an automated e-mail to their creators. Here is a good explanation of how that’s done including a code example.


Today’s Achievements

This is how our story board looks like today.

I spent most of the day working on our must have user stories marked in red. I also made a few code improvements already, making some code that I knew wouldn’t change anyhow shorter, safer and more efficient. I had to pull back the story on creating new application records back into the “In Development” bucket after discovering the already mentioned error today. The other two must have stories are close to being finished already, as we are already able to track 3/4 metrics we require (more on that in one of the upcoming posts) and the E-Mail notifications are also not far from being finished. This means full steam ahead to find the error that I described in “Handling User Roles”!
(click to enlarge)


Day 8 Summary

If you’re following along, start focusing on getting all your must have user stories developed. If you’re done with those already, pick your highest prioritized should and nice to have stories and keep on improving your solution.


That’s it for Day 8! Tomorrow we’ll focus on (hopefully) finalizing our functionality, improving, securing and testing our code and making some user interface improvements.


Meanwhile, sign up for the email-newsletter and I’ll let you know when the new posts go online!

Leave a Reply

Your email address will not be published. Required fields are marked *