VirtualTam's bookmarks
9 bookmarks found
Page 1 of 1
-
Note: each input source (keyboard, external keyboards) must be configured separately
-
Kubernetes Best Practices - GCP Blog
2018-09-28 - https://cloudplatform.googleblog.com/2018/04/Kubernetes-best-practices-how-and-why-to-build-small-container-images.html
- https://cloudplatform.googleblog.com/2018/04/Kubernetes-best-practices-Organizing-with-Namespaces.html
- https://cloudplatform.googleblog.com/2018/05/Kubernetes-best-practices-Setting-up-health-checks-with-readiness-and-liveness-probes.html
- https://cloudplatform.googleblog.com/2018/05/Kubernetes-best-practices-Resource-requests-and-limits.html
- https://cloudplatform.googleblog.com/2018/05/Kubernetes-best-practices-terminating-with-grace.html
- https://cloudplatform.googleblog.com/2018/05/Kubernetes-best-practices-mapping-external-services.html
- https://cloudplatform.googleblog.com/2018/06/Kubernetes-best-practices-upgrading-your-clusters-with-zero-downtime.html
-
Packaging Cython applications
2017-05-02 - http://stackoverflow.com/questions/37471313/setup-requires-with-cython
- http://stackoverflow.com/questions/35497572/using-python-setuptools-to-put-cython-compiled-pyd-files-in-their-original-folde
- http://stackoverflow.com/questions/32528560/using-setuptools-to-create-a-cython-package-calling-an-external-c-library
- http://stackoverflow.com/questions/22214022/how-to-run-nosetests-in-a-project-using-cython
-
C+Python and core dumps - Stack Overflow
2017-04-26 - http://plasmodic.github.io/ecto/ecto/usage/external/debugging.html
- https://lists.gt.net/python/python/1132756
1$ gdb --args python script.py 2[... GDB info ...] 3(gdb) run 4[... oooh crashes \o/ ...] 5(gdb) -
CMake: How To Find Libraries
2016-11-15 -
Python unit testing frameworks: Nose, Pytest
2015-02-13 Python's built-in unittest module is quite cool, but a bit limited and way too verbose (read: it's quite not easy to incite developers to write unit tests)
I'm currently looking for more dev-friendly solutions, the key points being:
- writing test code should be easy and straight-forward -keep the focus on "what to test" instead of "how to transcribe a process to a test"
- parallelization! -we, spoiled developers, should make good use of our way-too-many-cores build machines...
- complete feature set!
- we don't want to just run tests...
- coverage reports (find dead/weak/untested code sections)
- output formatting (JUnit-XML seems to be quite a common format out there)
There seem to be 3 solutions in Python:
- stock unittest + project-dependent customizations / test helpers
- nosetests
- py.test
And 2 ways of gettings things done:
- keeping things stock: no external dependency, project-specific implementation...
- using a test framework: one more module in your (test) virtualenv, more concise tests, more features (// run, code coverage, etc.)
Some links:
Page 1 of 1