Yesterday I said I would be spending all of today on getting the entries page done. I did work on the date parser part of the entries view function, but I didn’t fully implement the views function yet.
Initially when I thought of building the Daily Standup Meeting Logger, I decided to give one single master password and whoever wants to access it, will just type the password to login.
- But whenever someone leaves the team, you have to reset the password.
- If the password is leaked, because someone decided to write it down on a post it, you have to reset the password.
- And giving different set of permissions for developers vs non-developers with a single password is hard.
Since I already have a users table with all types of users in the system, I decided to add a password field to it. I hate having to handle user’s authentication and would prefer to not have a password based authentication at all. But for the v0.1 milestone that I have set for Sunday (16 April), I decided to go with the traditional route of having a email/password combo.
Lot of people make mistakes when storing passwords. I don’t want to reinvent the wheel, so I just use bcrypt for hashing the passwords. Flask-Bcrypt is a very easy to use extension which handles salting and hashing the passwords.
Even though an user system is available, the only way to add new users is through the flask shell command line tool or insert queries in the DB directly. I think for v0.1, I can live without an UI for user management.
Second part of what I did today was to slap on a Bootstrap base template for the project so that the UI looks pretty. Bootstrap is my preferred way to get out of designing a good user interface.
Though the base template is put in place, I have integrated only the login template with bootstrap. I haven’t even written the views for displaying or updating the entries.
Tomorrow I will be concentrating on adding/updating/viewing the entries.
Everyday at work, the first meeting (of the numerous ones) we have is the backend team’s daily standup meeting. This is an important meeting because this is the only time and place where we get to discuss what we would be working on to build/improve the main platform/product of the company.
We also discuss on what pending delivery items are there and what is in each team member’s todo list. There are other standup meetings about what we have for day’s delivery and that doesn’t exactly follow a template of a standup meeting.
Yesterday I wrote about how to use a very simple timing context manager to measure how much time your python code/functions take. There might be times when you want to restrict how long your code executes. Python’s
resource module in the standard library gives you an easy way to do that and more.
There are many times when you would want to see how much time your program takes to execute. The easiest way to do it on a unix system is to use the
time command before running the program.
Technical Debt is a term that most developers have heard of. Even if you haven’t heard of the term, I am pretty sure you would have done something in your programming career that is a technical debt.
Technical Debt is a metaphor referring to the eventual consequences of poor system design, software architecture or software development within a codebase.
In most cases, it is that quick and dirty hack your manager asked to put in just so that he could deliver it to the client.