Wayne Lambert
I have been learning Python since May 2018. Having studied many books and video courses and built a variety of projects using the skills learned, I have used Python for OS scripting, web development and data analysis/visualisation tool.
I have used a variety of libraries within the Python and Anaconda ecosystem and have an extensive knowledge of the extended standard library. Amongst many others, I have a good working knowledge of libraries such as itertools, functools, and collections.
Although the need for some of the tools within these libraries is not always required, it's useful to know for when you would like to build more efficient code or a standard data structure just doesn't give you the required functionality.
There are also examples of using these non-standard data structures within the Countdown Letters and Countdown Numbers apps.
I also have a good working knowledge of some of Python's common libraries such as Requests and Beautiful Soup .
Having developed several projects in Django including the whole of the portfolio that you're currently reviewing, I have developed significant skills with it.
Although nowadays I have starter projects to kickstart quickly, I can efficiently build a site from scratch using Django and overcome many of the obstacles in Django that the community considers to be advanced usage. Examples include:
I have used pytest exclusively as my testing framework of choice. I see very little reason to be using Python's built-in testing framework since the pytest API, community, and plugin ecosystem is so good.
In addition to standard pytest, I have a good working knowledge of pytest-django, coverage, some mocking libraries such as factoryboy and mixer, and an evolving knowledge of hypothesis.
I would love to improve my knowledge of hypothesis more as I can see how extremely powerful it can be.
Within this portfolio project, you can see many examples of testing of models, views, urls, and forms. Somewhat controversially, I also test the project's settings. To me, this seems like a sensible thing to do, although I appreciate many others disagree.
If you, or someone else on the team, changes a project setting which is imperative for the project to function correctly, they may not be aware of the breaking change. It might not even show up in the running of an extensive test suite. Some of the project's settings are in place for the front-end to function correctly. If there is a failing test for a setting, it at least prompts the question, "are you sure this project will continue to function as expected by changing this setting?" If the programmer is sure, they can always just change the test.
In addition, and certainly where I have control of an external site's 404 breakages, I test links to external websites. I learned this after a large restructuring exercise where I grouped apps into an 'apps' directory and ended up breaking a lot of the external links which should have enabled the user to navigate to the relevant source code page.
I use PostgreSQL as the database of choice with all of my Django projects.
Some of the tasks that I can complete with PostgreSQL or Django/PostgreSQL: