What I learnt
Things I’ve learnt:
FOR DEVELOPMENT - Using git - best practices:
Best Practices for Using Git:
- Commit Often: It’s better to have many small commits than one large commit. This makes it easier to understand the history and roll back changes if necessary.
- Write Meaningful Commit Messages: Commit messages should be clear and descriptive. They should explain the “why” behind the changes, not just the “what.”
- Use Branches: Always create a new branch when working on a new feature or bugfix. This keeps the master branch clean and deployable.
- Merge Carefully: Before merging branches, make sure to test your changes. This helps in maintaining the stability of the main branch.
- Pull Before You Push: Always pull the latest changes from the remote repository before pushing your changes. This reduces merge conflicts.
- Resolve Conflicts Promptly: If there’s a merge conflict, resolve it as soon as possible. This keeps the codebase clean and reduces technical debt.
- Backup Regularly: Even though Git is a version control system, it’s still a good idea to have backups of your repository.
Powerful Uses of Git:
- Collaboration: Multiple developers can work on the same project simultaneously without interfering with each other’s work.
- History: You can view the entire history of a project, see who made which changes, and when.
- Branching and Merging: This allows for parallel development. Developers can work on features or fixes in isolation and then merge them back into the main codebase when ready.
- Rollbacks: If a bug is discovered, you can easily roll back to a previous stable version.
- Blame: If you’re trying to figure out when a particular line of code was introduced, the git blame command shows you the commit and the author.
- Stashing: If you’re in the middle of something and need to switch tasks, you can “stash” your changes and come back to them later.
- Integration with CI/CD: Git can be integrated with Continuous Integration and Continuous Deployment tools to automate testing and deployment.
SYNTHESISING INFORMATION - Malcolms notes
Data Privacy Policies are no joke - avoid the HR functionality until you have serious security / privacy concerns addressed.
This could mean just storing the following user information:
- Name
- Email (hashed)
- Password (hashed)
- Role
- Location
The data privacy policy in place for interim is that we store those items, and delete them after deactivation for a year.
Use breakpoints - until you are going through the code line-by-line to see what it’s doing you’re probably wasting your time
Use breakpoints so that the app runs until this certain point. Then it should be going through each line.
Use this to get to the area of interest or where the bugs are happening.
Use git - use it for version control
The best thing is to be able to develop modules in isolation. This makes sure it’s disentangled from the workings of the other parts of the application.
Also means that there’s some work to integrate it within the existing application but that it should be relatively straightforward process.
There’s no magic bullet in learning - but here’s some ideas:
- Don’t go to Youtube first
- Check out some “Hello World” tutorials as a starting point
- Check stack overflow for what are common problems with developers and languages
- Work off of other projects - check Github for those specific language projects
- Google how to convert from languages you are more comfortable with to the target language
- Check out “cookbooks”, the language’s documentation, consider purchasing an O’Reilly Media book on the target language.
Sticking to a programming paradigm is useful - but also know when it’s a hinderance and to not use it
For example, SOLID is a useful tool to creating applications that are easier to maintain, build upon, debug, et cetera.
But there are trade-offs to following any paradigm strictly. It’s important to understand when to break the paradigm when it makes more sense for the specific application.
It’s not a prison, but a tool to keep you from having nightmares later.