VirtualTam's bookmarks

    1. The Technologies - A more in-depth look at Rust plugin systems
    2. Getting Started - First steps trying to implement the plugin system
    3. Diving into Dynamic Loading - A closer look at dynamic loading in Rust
    4. Reducing the Pain with Dependencies - Taking a look at the state of dynamic loading in the Rust ecosystem
    5. Getting our Hands Dirty - Finally implementing the plugin system!
    6. Wrapping Up - The last finishing touches and ideas
  1. This is what war in the 21st century looks like: you can practically monitor a missile or a drone that is trying to kill you right from your phone. This is like a Black Mirror episode in real life.

    1. Blocking TCP port 53 traffic leads to very strange failures. Don't.
    2. The source you're looking at is not the code running in production.
    3. "Prod" is just another name for "staging".
  2. A whole buncha' links with contradictory information on how to properly set up a mail server ;-)

    Disclaimer - My primary goal is to add proper Spamassassin (SA) filtering to an existing Postfix / Dovecot / roundcube installation, i.e.:

    • use SA as a milter (mail filter) to attribute a spam score to incoming mail
    • keep SA up-to-date
    • train SA with spam/ham from the users' virtual mailboxes
    • train SA according to user decisions (actual user or trained mail client with automatic/trained spam detection)

    Here we go!

    Most useful links; I stumbled upon them as soon as I knew what to look for:

    Official:

    Debian:

    CentOS:

    RHEL:

  3. "Any way you look at it, a drum solo is a shitty gift for a newborn!"

  4. 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:

  5. Framadate 2014-11-29

    Studs => OpenSondage => Framadate

    A doodle-like event scheduler.

    Though it seemed a bit crippled when I attempted to fork it early '14, it looks like it has gained in maturity, thanks to Framasoft's efforts ;-)

  6. Good-looking Shaarli fork ;-)