VirtualTam's bookmarks

561. Elpy, the Emacs Lisp Python Environment 2015-03-08

     tags: development, editor/emacs, ide, mode, programming/lisp, programming/python

     [ permalink ]
562. Iterables vs. Iterators vs. Generators 2015-03-03

     tags: development, evaluation, generator, iterator, lazy, list, programming/python, yield

     [ permalink ]
563. Misconceptions about testing (and what we should do about them) 2015-02-22

     tags: bug, framework/django, programming/python, programming/testing, quality, unit

     [ permalink ]
564. Kimchi: KVM web management interface 2015-02-14

     tags: linux, programming/python, sysadmin, virtualization, virtualization/kvm, web

     [ permalink ]
565. Become a Programmer, Motherfucker 2015-02-13

     tags: code, design, development, mofo, programming, programming/c, programming/c++, programming/java, programming/lisp, programming/python, software

     [ permalink ]

     Programming... Do you speak it?

566. Python unit testing frameworks: Nose, Pytest 2015-02-13

     tags: code, coverage, feature, nose, programming/python, programming/python/pytest, programming/testing, quality, unit

     [ permalink ]

     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:

     • http://stackoverflow.com/questions/22856638/nose-vs-pytest-what-are-the-subjective-differences-that-should-make-me-pick
     • http://helixyte.org/2014/04/unit-testing-adventures-moving-from-nose-to-pytest/
     • http://lists.idyll.org/pipermail/testing-in-python/2013-August/005624.html
567. Python: run specific unit tests 2015-02-13

     tags: bug, code, programming/functional-programming, programming/python, programming/testing, quality, unit

     [ permalink ]

     Given your unittests are in the tests directory:

      1# run a specific test module
      2python -m unittest tests.<module>
      3 
      4# run a specific test suite
      5python -m unittest tests.<module>.<class>
      6 
      7# run a specific test
      8python -m unittest tests.<module>.<class>.<test>
      9 
     10# run tests matching a given pattern
     11python -m unittest discover -s tests -p <pattern>
     

568. Homepage | Celery: Distributed Task Queue 2015-02-11

     tags: distributed, network, programming/python, queue, task

     [ permalink ]
569. Disabling electric indenting in Emacs modes - foldl 2015-02-07

     tags: auto, editor/emacs, electric, indent, mode, org, programming/python

     [ permalink ]

     electric-indent has been activated by default in emacs 24

     to disable it for Python: (add-hook 'python-mode-hook (lambda () (set (make-local-variable 'electric-indent-functions) (list (lambda (arg) 'no-indent)))))

570. Emacs as a Python IDE 2015-02-07

     tags: code, development, editor, editor/emacs, linux, programming/python, text

     [ permalink ]

     Very cool & detailed tutorial on how to setup Emacs for Python editing, completion & execution.

     https://github.com/jhamrick/emacs

571. python-measurement 2015-01-06

     tags: measurement, observability/metrics, programming/python, system, unit

     [ permalink ]

     https://github.com/coddingtonbear/python-measurement

572. Cobertura - Jenkins Plugin 2015-01-04

     tags: code, continuous-integration, continuous-integration/jenkins, coverage, programming/python

     [ permalink ]

     DIsplay code coverage stats

573. nose: python testing helper 2015-01-04

     tags: continuous-integration, continuous-integration/jenkins, coverage, parallel, programming/python, programming/testing, unit

     [ permalink ]

     Includes support for Coverage, Xunit and other cool stuff ;-) Oh, and there is parallel testing, too \o/

     nosetests --with-coverage --cover-erase --cover-tests --cover-html --cover-html-dir=htmlcov --with-xunit --xunit-file=unit.xml

     via http://www.alexconrad.org/2011/10/jenkins-and-python.html

574. Python - Don't do this! (Richard Jones, PyCon 2013) 2014-12-20

     tags: fun, programming/python, pycon, wtf

     [ permalink ]
575. Advanced Topics in Programming Languages Series: Python... 2014-12-14

     tags: development, programming/design-pattern, programming/python

     [ permalink ]

     Part 1: https://www.youtube.com/watch?v=1Sbzmz1Nxvo Part 2: https://www.youtube.com/watch?v=tJXhtncDBu4

576. MoinMoinWiki - MoinMoin 2014-12-14

     tags: engine, programming/python, web, wiki

     [ permalink ]
577. Reviewboard 2014-12-02

     tags: code, continuous-integration, development, framework/django, programming/python, review

     [ permalink ]

     https://www.reviewboard.org/ https://www.reviewboard.org/docs/manual/2.0/admin/ https://www.reviewboard.org/docs/manual/2.0/extending/

578. Dive Into Python 3 2014-11-30

     tags: best, development, migration, practices, programming-language, programming/python

     [ permalink ]

     A follow-up to Mark Pilgrim's http://www.diveintopython.net/

579. Continuous integration in Python 2014-11-27

     tags: automation, continuous-integration, continuous-integration/travis, development, programming/python, programming/python/pytest, programming/testing, source-code-management/git, unit

     [ permalink ]

     http://ilovesymposia.com/2014/10/01/continuous-integration-0-automated-tests-with-pytest/ http://ilovesymposia.com/2014/10/02/continuous-integration-1-test-coverage/ http://ilovesymposia.com/2014/10/13/continuous-integration-in-python-3-set-up-your-test-configuration-files/ http://ilovesymposia.com/2014/10/15/continuous-integration-in-python-4-set-up-travis-ci/ http://ilovesymposia.com/2014/10/15/continuous-integration-in-python-5-report-test-coverage-using-coveralls/ http://ilovesymposia.com/2014/10/17/continuous-integration-in-python-6-show-off-your-work/ http://ilovesymposia.com/2014/10/27/continuous-integration-in-python-7-some-helper-tools-and-final-thoughts/

580. gource - software version control visualization 2014-11-26

     tags: agile, commit, continuous-integration, development, game/minecraft, linux, observability/logging, programming/python, project, software, source-code-management/git, source-code-management/subversion, user, version

     [ permalink ]

     Uses a project or repository's history to plot user contributions, displaying an elegant, colored graph of the file arborescence.

     After running it on quite different projects...

     • Python/Bash CI/Jenkins scripts
     • Qt apps: GoldenDict, Psi+
     • PHP website: Shaarli

     ...watching some vids on teh intartubez:

     • Minecraft: https://www.youtube.com/watch?v=zRjTyRly5WA
     • Linux kernel: https://www.youtube.com/watch?v=AhDiYPLo3p4
     • Python: https://www.youtube.com/watch?v=cNBtDstOTmA

     It allows to arbitrary spot some interesting implementation aspects (sorted by descending impact):

     • language-dependent trees (oh hai Java packages ^^)
     • framework-dependent trees
     • project-management method (none, Agile, TDD)

     Having a graphical tool also quickly shows:

     • the overall structure of the project (a bit cooler than a simple $ tree, way quicker than loading the project on an IDE)
     • the repartition of files (by extensions)
     • who are the most active contributors
     • what are the most modified files over time
     • who does what: additions, deletions, refactoring

     Some more CI-related matters:

     • are there any tests?
     • what is the source code / test code ratio? (we could expect a project/lib with N modules to have at least N test modules)
     • who initiates / implements / optimizes test code?