How to code ? — 6
Being the user when you are not is the most difficult part of coding
Continuing from post-5 where we saw how we can design our CLI, we need to make the CLI take in parameters for automatically scheduled backups. This can be every hour or day or week. So if we have our CLI as
> bakitup -b <source folder1>,<source folder2> <drive>:<folder path> <frequency>
The frequency parameter can be <number>h or <number>d or <number>w, where h is hour, d is day and w is week. The number tells if the time between the backups. For example, 5h will mean every five hours or 2d will mean every 2 days.
This is pretty good, but what if the back up happens when the user is running other stuff on his PC? The backup will cause a slow down for other applications. Imagine the user doing some high intensity graphic design or playing a heavy duty game or training a ML model. All of this are disk and memory intensive. Backup running at that time will result in a slow down of those apps and can be frustrating.
So, it may be good if the CLI allows the user to specify a start time from which the above frequency applies. The user can choose the start time as something when he or she feels no productive stuff has to be done on the PC. So let us add this to the CLI.
> bakitup -b <source folder1>,<source folder 2> <drive>:<folder path> <start time> <frequency>
The start time is specified as MM:DD:YYYY:HH:MM
This means I can schedule as 10:20:2019:13:20 to run the backup around 1.20 PM every day noon, if the frequency is 1d, starting Oct 20, 2019. This is convenient as I will be lunching at this hour.
We do not have any such parameters for ‘restore’ as it is done at the behest of the user.
Now to summarize the CLI design so far,
> bakitup -b sourceFolder1,sourceFolder2,... drive:folderPath startTime frequency-b indicates backupsourceFolder1, sourceFolder2...and so on specifies one or more source folders from which files will be backed up.If the user does not give a sourceFolder, the folder where the bakitup was run will be taken as the only source folder.drive:folderPath indicates the target or destination store such as external drive or cloud stores. For this version, only an external drive is supported. folderPath specifies the path in the drive. This is a mandatory parameter first time bakitup is run.If a sourceFolder or destination folder does not exist or does not have read permission, bakitup returns an appropriate error.startTime is MM:DD:YYYY:HH:MM timestamp that indicates the time at which bakitup will be scheduled at the given frequency. If this is not given, the time at which bakitup is run as the scheduled time.frequency is by number of hours or days or weeks starting from startTime for scheduling a backup automatically. If this is not given, bakitup will run only the time it is run.
> bakitup -r drive:folderPath folder1,folder2,... restoreFolder-r indicates restoredrive:folderPath has same meaning as -b above.folder1, folder2,...are optional. User can restore specific folders from the backup drive. If this is not given, all folders that were given as sourceFolders in -b will be restored to their respective target folders.restoreFolder indicates a path to a folder where the backed up folders and files will be restored. If this is not given, restore will copy to the original source folders from which backup was done overwriting any updates that might have occurred after the last backup.
As you can see, when we design the CLI, it is a lot more concise in terms of the functions bakitup will do for its user. This is the most important piece of design of any application. These are the buttons and knobs the user can push to get the job done. So it better be precise and unambiguous.
Imagine if bakitup is running in the cloud and not on your PC. When you run backup or restore, it will trigger a URL on the server which in turn will accept the files being transmitted by the client and back it up to disk. The reason I am bringing this up is that in such a case, bakitup will be a client-server application and the above CLI will become the API (Application Programming Interface), typically exposed as a REST URL that a backup client running on a browser can trigger. This is an interesting possibility that can allow users without an external drive to run the backup and restore over internet. From a business side of things, designing such an application is lot more sensible as it has the potential to reach out to a large number of users. We will examine this as we go along. For now we will restrict ourselves to a PC.
See post-7 for design.
