Did the schedule program for tracking days / hours work?

Let's say I'm building a program that keeps track of work days and work hours, would I use a dictionary? And how would I be different from Monday in week 1 from Monday in week 2? How can I get it to store this information after the program is closed? (Python language)

+1


a source to share


3 answers


A dictionary is a good way to store data while your program is running.

There are several ways to add persistence to the data (this is after closing the program). Python's pickle and shelve modules are useful and easy to use. One problem is that you cannot easily check the data outside of a Python program. There are also modules for reading and writing text files in JSON and XML formats, and JSON is especially easy to read in a text editor.If you don't already have the knowledge, databases like MySQL are much more than you need for a personal program like you mentioned, and if you don't want to invest some time learning how to use them, you should go with an easier solution.



As for Monday in week 1 and week 2, you have many options. You can use an actual date (it seems like a good idea to me), or you can enter a dictionary with tuples like ("Monday", 1). The main rule is that dictionary keys should be immutable (ints, stringings, tuples - which only contain immutable objects, etc.), but not (dictionaries, lists, etc.).

0


a source


I would probably create a schedule object for each week or billing period. Each schedule object can have a collection of days, with hours worked or using time and time.



For persistent storage for a website, I would use a database like mysql. For an application running on a single machine, I could use pickle or a flat filesystem.

0


a source


I took the opposite approach when developing this application for my own use.

In my experience, the biggest problem with time tracking apps is data entry. So I decided that my application uses the simplest and most flexible data entry tool: a text editor. I am saving notes in a text file and mixing the timing entries in them, so the excerpt looks like this:

Monday 5/10/09

release script ok this week
open a case on the whole code-table-foreign-key thing

- CUS1 2.0 Generate and release version 1.0.45.

need to get dma to spec out the RESPRB configuration, see case 810
MH section complete - one to go!

- CUS2 4.0 Configure and test Mental Health section.

Tuesday 5/11/09

... and so on

      

I agree to start each day with the correct heading, and the format of the actual timekeeping records, as you can see, is pretty simple. A simple scanner and state machine is all it takes to retrieve the data - basically, I just look for lines that start with a weekday or a hyphen and ignore everything else.

So that the program doesn't get too slow when parsing note files, I create a new note file every year. (Even at the end of December, the parsing process takes no more than 1/16 of a second.)

I wouldn't do it this way if I had to process the chronometer records of hundreds of people, because the user has to have a little hint and the parsing times will start to add up after a while. On the other hand, storing this data in a human readable text file that I can store in other stuff (and keep version control, and diff, etc.) is just incredibly useful.

0


a source







All Articles