Things that are crossing my path lately: Flit, in context of "Python Packages and You." Python packaging is not a strength of mine.I hate to say it, but the Democrats' rejection of Trump's offer to open negotiations about the government now look kinda stupid, based on their oppositions. They're saying that a three year suspension… Continue reading Flit, Trump’s Address on 19 Jan, Elite: Dangerous
Things I've learned recently: If you really want to know if you have value, post something of questionable worth on the Internet. You'll immediately have a bunch of people correcting you. That's not to say you should post anything harmful - for goodness' sake, don't do that - but post something that makes an assertion… Continue reading Wondering if you’re loved, literally?, python dependencies
Things I've learned today: tox is a Python library designed to "standardize testing in Python" - including testing a given project across Python versions (so you could use it to create a library for both Python2 and Python3, and test in both environments.) I'm working on such a library right now; I am using two… Continue reading JUCE, tox, Euclidean beats
This is a record of my experiences parsing JSON in a REST service written with Django, in Python. I'm following various tutorials (including Django's REST framework tutorial), but I was really struggling to get a snippet of JSON actually processed on the server side. The service in question was really quite simple: a name completion… Continue reading Python REST service with Django
Test-driven development is, loosely defined, a practice in which tests are written before anything else, without regard to correctness. For example, if I want to write a program to generate "Hello, world," I would write a test that validated that "Hello, world" was generated - before I had anything that might create the output. When my tests pass, I know I've "finished," because my tests define a specification. By having tests in place, though, not only do I have a record of the specification, but I also have a way that I can add to the specification in such a way that I know I'm not breaking code - I would simply add more tests that corresponded with the changing specification, and I will know if my changes break other code. Here's the thing: I wrote the Java implementation using test-driven development practices (TDD), and the automaton is kinda neat; TDD also provided me the opportunity to fix the names of structures (renaming `Dataset` to `Generation`, for example) because the tests made it obvious that the names were inaccurate. However, seeing the differences in the development process between my Python implementation and the Java implementation, I might look into TDD with Python anyway.