VirtualTam's bookmarks

61. So you want to speak at a conference…. | kate{mats} 2017-02-08

    tags: event/conference, presentation, slide, tech

    [ permalink ]

    • http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/
    • https://medium.com/@karen_meep/how-to-start-speaking-in-tech-conferences-f64a9f3a84a6
    • https://www.ashedryden.com/blog/what-you-need-to-know-about-speaking-at-conferences

    via https://dbader.org/blog/how-to-speak-at-a-python-conference

62. How do Nirvana's chord progressions all "work"? How do I write like that? 2017-02-02

    tags: chord, dissonance, music, nirvana, progression, scale

    [ permalink ]

    http://www.losdoggies.com/archives/2906

63. What I learned from writing six functions that all did the same thing 2016-12-20

    tags: array, loop, mathematics, programming/javascript

    [ permalink ]
64. Howto write apache ProxyPass* rules in HAProxy | HAProxy Technologies – Aloha Load Balancer 2016-12-06

    tags: content, network/http-server/haproxy, network/reverse-proxy, network/url, response, rewrite, sysadmin

    [ permalink ]
65. robbiebarrat/rapping-neural-network: Neural network that can "write" rap songs -- other python files help it deliver the raps. 2016-12-01

    tags: lyrics, neural-network, programming/python, rap

    [ permalink ]
66. "If you prick us, do we not bleed?": Introducing a poetry-writing bot, W. S. Bardbott : botsrights 2016-08-24

    tags: bard, bot, poetry, reddit

    [ permalink ]

    bot @ https://twitter.com/bardbott poetry discussion @ https://www.reddit.com/r/Poetry/comments/4yw9x0/general_if_you_prick_us_do_we_not_bleed/ code? @? https://github.com/quadrismegistus

67. How to Write a Spelling Corrector 2015-12-10

    tags: check, corrector, development, language, natural, programming/python, spell, typo

    [ permalink ]
68. Learn to write Gallifreyan in 9 simple steps 2015-07-17

    tags: doctor, gallifrey, hack, image, language, space, time, who, word, write

    [ permalink ]

    http://timeturners.wikidot.com/circular-gallifreyan http://www.shermansplanet.com/gallifreyan http://www.wikihow.com/Write-in-Gallifreyan

69. Writing testable code 2015-05-12

    tags: code, development, programming/testing, unit

    [ permalink ]
70. Martin Fowler 2015-04-05

    tags: agile, computer, continuous-integration, development

    [ permalink ]

    "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

    see http://martinfowler.com/articles/continuousIntegration.html ;-)

71. Let Over Lambda 2015-03-18

    tags: development, list, lol, macro, meta, programming, programming/lisp, recursive

    [ permalink ]

    This book is about macros, that is programs that write programs.

72. Building an ARM cluster 2015-03-15

    tags: arm, beaglebone, cloud, computation, distributed, distributed-system/cluster, hack, linux/container/docker, network, odroid, sysadmin

    [ permalink ]

    http://mkaczanowski.com/building-arm-cluster-part-2-create-and-write-system-image-with-goback/ http://mkaczanowski.com/building-arm-cluster-part-3-docker-fleet-etcd-distribute-containers/

73. 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
74. CI is hard! « Jacob Kaplan-Moss 2014-11-24

    tags: buildbot, continuous-integration, continuous-integration/jenkins, development, framework/django, programming/python, programming/testing, unit, web

    [ permalink ]

    http://jacobian.org/writing/ci-is-hard/ http://jacobian.org/writing/configuration-and-architecture/ https://github.com/jacobian-archive/django-buildmaster

75. Learn X in Y Minutes: Scenic Programming Language Tours 2014-10-23

    tags: development, programming-language, syntax

    [ permalink ]

    TL;DR: you won't.

    This website is rather a good memo regarding each language's foundations:

    • what's its general purpose?
    • how to write core instructions, such as functions, loops, conditional structures?

    I find this kind of reminder quite useful when it comes to documentation languages (e.g. TeX, Markdown)

76. Writing with Vim - jasonwryan.com 2014-06-23

    tags: console, editor, editor/vim, linux, programming/shell, text

    [ permalink ]
77. How to write unmaintainable code 2014-01-09

    tags: code, development, programming, programming/java, tricks, ugly, unmaintainable

    [ permalink ]