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 of some of the deportations and other such hot-button issues … basically, getting the things they wanted was not enough. They’re idiots. Sure, he is one, too… but the whole three year delay for the application of law gives Congress three years to fix the law, which is what Trump said they should do when he said he was going to resume deportations in the first place! In other words, from me to them: Congress, do your flippin’ jobs. If Congress wasn’t relying on executive power to do what Congress was meant to do, a lot of this mess would have gone away, but they keep digging in their heels and saying “no.”
The worst thing about Elite: Dangerous is how long it takes to get into a gaming session. The best thing about Elite:Dangerous is “pretty much everything else.”
I just realized I can select a region in WordPress’ editor, and then paste a URL – and the region is converted to an HTTP anchor automagically. Now that is useful.
Few things are both more and less amusing than watching someone stomp about, screaming “I am not a prima donna!”
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 of some kind. People will notice. This is a great way to see who really should be off your communications grid, too. 🙂
The previous point was not an attempt to be passive-aggressive. If you think you’ve been caught in such a net by me, well, I apologize; reflect on your own time if you think you do that, and leave my what-I-thought-was-mildly-humorous complaint out of it. Thanks!
I still find it difficult to abandon my youthful habit of using Anglican spellings for everything. Typing “humorous” without the extra “u” – i.e., “humourous” – is difficult for me even now, for example. It was with a sense of palpable relief that I typed the “wrong one” as the example.
This is a great sentence: “Don’t write silly-soundingly,” as found in “Yes, I Could Care Less,” as a quote of Jesse Sheidlower on Slate. Man, references at a deep depth are rough. My middle son gave me “Yes, I Could Care Less” as a gift – and it’s a good one. Thoroughly enjoying it so far.
poetry is another python dependency management tool, like pipenv. Work uses pipenv; I might check out poetry just to see what it’s like.
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 shells, two directory trees, two virtual environments… which is a pain. tox looks like a library to help me get around that.
JUCE is a library designed to help delivery music … applications. It has the ability to generate UIs, VSTs, AAX plugins using C++. One of the things I keep thinking I want (although I’m not sure I actually do) is a Euclidean beat generator; I also wouldn’t mind doing a cellular automaton to generate music, so JUCE looks interesting. I haven’t done C++ for real since my Alcyone project (my MIDI foot controller hardware) so I might have to approach this slowly.
I like this format of data capture more than I enjoy sites like Twitter. Sure, Twitter’s probably fine for simple assertions, but I don’t like simple assertions; there’s no room for nuance, and in the real world, there’s… nuance. So far, this allows me to make an assertion and explain it without worrying about incomplete, piecemeal consumption. I just have to build the habit, and work on classification.
Since I mentioned it earlier: Euclidean beats are apparently found in real world musical forms, and that’s kinda awesome… but every time I’ve played with them, I don’t care for the output much. Euclidean beats tend to be regular (therefore, well, Euclidean) and my own percussion approach, when I focus on it, tends to focus on the unexpected hits rather than regularly timed hits. Euclidean beats spread out hits over known periods; I cluster hits inside those known periods instead. Which approach is better? Well, you can find famous percussion virtuosos who use Euclidean approaches, and I’m neither famous nor a percussion virtuoso. Hmm.
Wildwood Guitars has amazing prices on Rickenbacker guitars, and from what I’ve been able to tell from asking Rickenbacker players and from community reviews, they’re quite well respected. And yes, they carry the basses – and have used equipment as well.
While I’m thinking about Rickenbacker basses – which happens a lot more than I expect it should, really – there are two main products, the 4003 and the 4003S. The 4003 differs in the fretboard inlays (the 4003 has a sharktooth inlay, the 4003S has a dot) and the 4003 has two outputs (“Ric-O-Sound”, where each pickup has its own output jack) and the 4003S has only a single mono output. The 4003 also has a bound body and the 4003S is unbound; apparently some people find the unbound body more comfortable. I have not done this comparison myself… but if I were to figure out my ideal Rickenbacker bass, it’d be a Midnight Blue 4003, although the others are pretty too. I do not have a Rickenbacker bass, nor is that likely to change, as I’m not a working musician and I don’t need another bass to replace my Jazz… I’d just like a Rickenbacker just because.
I find it extraordinarily difficult to trust Donald Trump. His wife shouldn’t trust him, and his ex-wives clearly shouldn’t have trusted him either; why should I trust him, when the people to whom he owes trustworthiness most can’t rely on him? And he employs “the best people”… and doesn’t trust their expertise when it suits him to counter their opinions. Yeesh. We elected this guy. I hope we deserve better.
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 service, given a band name in a Suggestion object.
The bandcompletion method actually does the work of returning a JSONResponse – this is basically a wrapper method to accept JSON from the body of a POST request.
I was unimpressed with the sequence: I get a str from request.body, but then I have to convert it to a stream for JSONParser.parse (with BytesIO), which was actually the point at which I was getting lost. Apart from that – which I think was obscure only to me – everything was pretty straightforward.
Postman can submit the data as raw body text for the request as well.
There’s no error checking here yet, and the error message for the wrong method is terrible, but all of that is going to be fixed. I’m still playing around.
Exciting stuff, I know, but I’m a big believer in recording things I find significant, just so other people can correct me, or learn from me if I managed to see something they didn’t.
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.
“Test-driven development” is one of those things that causes hives among some programmers, who immediately stand up and plant the claim that it’s worthless, peurile, deceptive, and generates awful code… never mind that others manage to use it effectively.
I have been playing with a 2D cellular automaton, largely inspired by Stephen Wolfram’s “A New Kind of Science.” I have a version in Java, and a simpler implementation in Python. TDD made the Java version work properly, and a lack of TDD left a hole in the Python version.
“A New Kind of Science” wasn’t the only inspiration, of course. A friend of mine published a Javascript version of Conway’s Game of Life – a 3D automaton that’s pretty well-known – and a differentfriend of mine was looking for simple projects that he could use to help teach kids how to program, and a 2D automaton came to mind – so he asked for an implementation, which is why I wrote the Python version of the automaton.
This post is not about the automaton itself. I’ll write that up later. (If you’re interested, you can see the source.)
What is TDD?
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. My tests would fail; they wouldn’t even compile until I had some sort of implementation written.
However, by writing a test before anything else:
I more or less force myself into having some sort of specification that says what “correctness” means for my program (it is “correct” when it generates “Hello, world”)
I also force myself into writing something that has a reasonable interface (because I’m writing how I think it would be called, before writing the guts of the implementation)
By writing the tests first, I’ve effectively given myself a criterion for completeness. When my tests pass, I know I’ve “finished,” because my tests define a specification.
There’s nothing wrong with the specification being incomplete, of course; it may so happen that later, I want to greet someone specific. 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.
How did TDD work out for my Automaton?
Here’s the thing: I wrote the Java implementation using test-driven development practices (TDD), and the automaton is kinda neat; it generates some fascinating patterns even without entropy or a variable starting cell structure. An example, of pattern 171, using a color rendering mechanism:
The Python version was written because a friend of mine wanted to consider using it for a class he’s teaching. The Python version is very much simpler than the Java version, because it doesn’t do as much (it can’t output to multiple formats, for example).
It was not written with testing in mind. Why would it be? I had written the Java version from tests first; I was only writing a simple port to Python.
It was also wrong. A 2D automaton can “grow” to the right and to the left, depending on the pattern it’s given; the Python version could only grow on the right, because I had an off-by-one error in a core routine.
TDD would have caught that early (and it did catch problems like that, in the Java version).
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.
Could I have done it without TDD? Of course. TDD isn’t the only way to write programs well. It’s not the only tool used to work out good names, or good processes, or even to validate that programs work properly – the Python version of the automaton was fixed without TDD, for example.
If you’re wondering why I didn’t use TDD for the Python version, it’s because I’m too much of a newbie with Python to know how, yet – and as I’m not really a Python programmer, there’s not a lot of need. However, seeing the differences in the development process between my Python implementation and the Java implementation, I might look into TDD with Python anyway.
