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.
Blogs are so yesterday, man. It’s probably the medium and platform I’ve chosen – I don’t use Medium, for example, although I have an account there – and I don’t publish often enough, or with enough direct focus, to really attract users, because I’m really not trying to build a popular platform. But at the same time, my pride is hurt just a little that traffic is so low.
Crawler4j makes it really easy to write a working web spider in Java – or, in my case, Kotlin. Looked into scrapy for a bit, but couldn’t figure out why what should have been a trivial recipe was so hard to find, switched to Kotlin because I really just needed to make progress. Progress was made. Scrapy’s probably fine – maybe the information I was looking for was out there, right in front of my face, and I couldn’t recognize it, but that didn’t help me make the progress I needed.
Had a good example of pragmatism in action show up yesterday, too. We issued a pull request for a migration, and one of our developers pointed out a number of situations in the new codebase that could have been problematic. I asked him to demonstrate the errors (or potential errors) with tests so we could validate them, but he wasn’t sure how much effort would be involved in writing those tests… so we progressed with the merge. I think we made the right choice; he’s not wrong in his observations (we might have introduced errors with the new changes) but without validation, we can’t know, and we’d be chasing ghosts. We made notes that the code might be problematic, and we’re going to watch for problems that come from it.
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.
Recently, someone said that I needed to put more of the things with which I’m experienced on my resumé. They’re right, but it’s not an easy task, for a few reasons.
The main reason is that it’s too long. If you can name a mainstream language, chances are I’ve done something meaningful with it. Perhaps it’s not been a major project, but I’ve probably kicked the tires of each language enough to understand what it’s about, the paradigm of the language and ecosystem.
It’s not just limited to mainstream languages, either. There’re some obscure languages that litter the landscape, like Louis II, and even some custom languages, including some to which I contributed.
More than languages, it’s libraries. Java is one language, but it has thousands upon thousands of libraries and utilities providing functionality for application developers. Those libraries range from frameworks like Java EE to Spring, all the way down to matrix and artificial intelligence libraries and over to tiny utilities that just make tasks easier.
The problem here is how to specify with what I have experience, in such a way that my experience stands out in useful fashion.
The other main problem is how and why I have that experience, and what that experience means.
When I was in my twenties, and I’d not used C++ for a few years, a friend of mine and I sat down for what would now be a pair programming session. It’d been a while for C++ and me; I remembered what do to, but when confronted with the actual blank screen, I spaced.
I don’t remember what we did next; we probably played guitar for a while.
That moment stuck with me, though. It hit me again when I was working on the Alcyone, my MIDI foot-pedal controller project, which is written with C++. When I sat down to write it, my first thought was vague panic: how well did I remember C++? Was I good enough to get it done well? (The answer was: well enough, and yes, thank you.)
I use that sensation all the time. It was the basis of my employment by TheServerSide as editor in chief, the guy who’s supposed to vet content for quality and accuracy, and the guy who’s supposed to provide an actual perspective.
And there we have another problem with my experience: depth.
A while back, someone lambasted the Miami Hurricanes’ fanbase, pointing out that it was a mile wide and an inch deep; all their fans are band-wagoners. (When the team does well, they’ve been fans forever; when the team struggles, well, the beach is over there, are the ‘Canes playing today? By comparison, we Florida State fans are actual fans.)
Well, that’s me and a lot of technology, honestly: because TheServerSide watched everything, generally from Java’s perspective but not limited to Java, I encountered it all. Every obscure library wanted to be promoted, so I’d get notices of everything.
I read hundreds of posts a day, trying to understand not just the posts themselves, but whether they were relevant for a wide enough audience that I needed to tell my readers.
Once I decided that a topic was relevant, I had to write it up in such a way that I was actually trying to explain it to my readers. That meant I couldn’t see some obscure fuzzy logic library and think “Oh, that sounds neat,” and then copy and paste some blurb from the project website.
I had to download the project, perhaps build it. I had to understand the problem domain the project was trying to address. I had to try to use it, to see if the project’s claims were accurate, and to see how I actually felt about how it was used.
Therefore, my experience wasn’t just a mile wide and an inch deep – I had to approach everything, and build my experience to the point where I could conceivably use the project to actually do something. I had to come at everything with my tiny grains of knowledge and build a fortress against the ignorance, so I could tell others something they needed to know, whether they knew they needed it or not.
It wasn’t an easy job.
However, that was perfect for me: it played into my skills as an architect, and as someone who integrated information quickly and well, and into my desire to connect people with information.
However, how do I use all of this? Well, as a architect and a consultant, I’m good at approaching problems cold, and seeing how possible architectures map to those problems; I am not limited to seeing things from Spring’s perspective, or Hibernate’s, or Mule’s, or Rails’. I’ve used them all, and I have a good idea about what I think works well, and why, and where they don’t work well.
And if I’m wrong? Well, I don’t let my ego carry me too far down a wrong path; I know I’m human, I know I rely strongly on my ability to integrate and learn. So what, if I recommend Spring for something at first, and find that something else would be better? I had to learn, and I do learn.
So the issue with my experience is two-fold: it covers too much to be useful, and the best aspect of it is the experience of using and learning, as opposed to raw mastery of a given limited set of technologies.
I’m not really sure how to leverage that in the cold light of a resumé.
