Topic: Posts

I've always enjoyed watching television while knitting, knitting itself is easy and doesn't take much thought most of the time, and I've never needed to watch it for every stitch, so it makes sense. I've never really felt as engaged with audio-only media while knitting for long stretches, though I do try sometimes.

My tastes, in this context, tend toward procedurals: not particularly because I love crime and/or medical shows, but because the cadence of the story telling is a good fit for my attentional needs while knitting, and the overall predictability means my attention can drift in and out as need be. It's also helpful that a lot of procedurals have had long runs which means there's a lot of material to keep me busy. Things that I've watched recently:

• Bones has been quite fun to watch because it sort of fits the bill correctly, there are a lot of episodes. It's also very interesting because I remember watching some of the early seasons more or less when they aired, and it totally feels dated now.
• Stargate Universe, which couldn't stick with, despite a lot of affection for earlier Stargate shows, I couldn't stick it out. I think that some combination of the show being very dark and isolating, with a few of the characters being deeply unlikeable.
• The last few years of Star Trek TNG and Voyager. Which were nice, but it's super weird to watch television that's this episodic, and while I've watched a lot of Star Trek here and there, I must confess that I didn't really watch them systematically before.
• Eureka is totally absurd, but was fun to watch, and was the right kind of "delightful, but mostly lighthearted."
• White Collar has been fun. I'm particularly partial to shows set in New York City, and it's fun to be able to pick out the settings from familiar places. Sometimes the characters are great, and sometimes some of the "character growth" stories are a little bit ham-fisted. I also wonder what'd be like if there was a buddy-cop show where there characters were actually gay and not just incredibly homoerotic all the time.

I'm not super sure where to go after this, and would gladly take suggestions if people have favorites. I haven't tended to enjoy things like CSI very much, for whatever that's worth.

While I took a bunch of time off knitting, I didn't quite take enough time off to completely divest myself of all of my knitting things, which means when I decided rather abruptly that I wanted to start knitting again, I just had to run and pull a couple of boxes down off a shelf and I was off to the races. At the same time, after many years of small apartment living I didn't have a very large collection of gadgets or yarn.

While I don't really have a great interest in building a collection of knitting things, or yarn outside of material I have proximal use for, in the nearly 10 years, since I was a regular knitter, the state of the craft has evolved or at least changed a bit. While my collection of things hasn't changed much, the following objects

• knitting needles, have always been complicated. I tend to work at fairly small sizes which makes needle flex/bend an issue, and my skin tends to react with nickle which rules out a lot of options.
  • at my mother's recommendation I got a few Dyak Craft knitting needles. The small-sized interchangeable needles are great, and the US 0s (which has been my primary needle) don't bend or flex at all, and have good cable/needle joins.
  • I have a small collection of 5 inch carbon fiber, double pointed needles in some small sizes and I think they're just perfect. I'm a loose knitter, so the little bit of grip that they have is great. Somehow, metal needles and six inch needles end up hurting my hands, and I've never used a pair of wooden needles that haven't broken tragically.
• After a couple of projects where I was just breaking the yarn by hand, or using kitchen scissors, I gave in and bought a 4 inch pair of very plain Gingher embroidery scissors (for 20 bucks,) and they're brilliant for trimming threads and cutting open steeks. As a left handed human, scissors have always been something of a sore spot, and these are quite good.
• I bought a couple of boxes of those lightbulb-shaped coil-less safety pins. I think the going rate is 6 bucks for a pack of 120, and they come in a few different colors. These are great both as stitch markers for the needle, and also to mark rows while knitting.
• When I was going through my knitting things, I very quickly found a little cone of 8/2 mercerized cotton that I've had for years in lime green--a color I've never even gotten close to knitting with--that's really perfect for setting stitches aside or for provisional cast-ons. It's nice to use smooth, non-wool yarns for this purpose, and you don't use very much of it, but it's great to have around. While I've had this cone for 16 years or more, and it's conceivable that I may never finish it, it's great.
• I've also given in a started storing in-progress knitting projects in draw-string canvas bags purpose built for knitting/crafting, as opposed to the vinyl bags that bed-linens come in, which had previously been my default. It's pretty essential that I be able to keep things safe from cats or the other things in my backpack (not that I leave the house much these days,) so containment is necessary, and avoiding velcro and zippers is ideal.

And that's about it!

Editoral Note: this is a follow up to my earlier Principles of Test Oriented Software Development post.

In software development, we write tests to make sure the code we write does what we want it to do. Great this is pretty easy to get behind.

Tests sometimes fail.

The goal, is that, most of the time when tests fail, it's because the code is broken: you fix the code and the test passes. Sometimes when test fail there's a bug in the test, it makes an assertion that can't or shouldn't be true: these are bad because they mean the test is broken, but all code has bugs, and test code can be broken so that's fine.

Ideally either pass or fail, and if a test fails it fails repeatedly, with the same error. Unfortunately, this is of course not always true, and tests can fail intermittently if they test something that can change, or the outcome of the test is impacted by some external factor like "the test passes if the processor is very fast, and the system does not have IO contention, but fails sometimes as the system slows down." Sometimes tests include (intentionally or not) some notion of "randomnesses," and fail intermittently because of this.

A test suite with intermittent failures is basically the worst. A suite that never fails isn't super valuable, because it probably builds false confidence, a test suite that always fails isn't useful because developers will ignore the results or disable the tests, but a test that fails intermittently, particularly one that fails 10 or 20 percent of the time, means that developers always will always look at the test, or just rerun the test until it passes.

There are a couple of things you can do to fix your tests:

• write better tests: find sources of non-determinism in your test and rewrite tests to avoid these kinds of "flaky" outcomes. Sometimes this means restructuring your tests in a more "pyramid-like" structure, with more unit tests and fewer integration tests (which are likely to be less deterministic.)
• run tests more reliably: find ways of running your test suite that produce more consistent results. This means running tests in more isolated environments, changing the amount of test parallelism, ensure that tests clean up their environment before they run, and can be as logically isolated as possible.

But it's hard to find these tests and you can end up playing wack-a-mole with dodgy tests for a long time, and the urge to just run the tests a second (or third) time to get them to pass so you can merge your change and move on with your work is tempting. This leaves:

• run tests multiple times: so that a test doesn't pass until it passes multiple times. Many test runner's have some kind of repeated execution mode, and if you can combine with some kind of "stop executing after the first fail," then this can be reasonably efficient. Use multiple execution to force the tests to produce more reliable results rather than cover-up or exacerbates the flakiness.
• run fewer tests: it's great to have a regression suite, but if you have unreliable tests, and you can't use the multi-execution hack to smoke out your bad tests, then running a really full matrix of tests is just going to produce more failures, which means you'll spend more of your time looking at tests, in non-systematic ways, which are unlikely to actually improve code.

This is the follow up to Pattern Fragment 0, Pattern Fragment 1, Pattern Fragment 2, and Pattern Fragment 3.

Cut open the arm hole steeks, and joining new yarn at the top of the opening (after the shoulder seam), pick up stitches around the arm hole, at a rate of 2 stitches for every three rows. I picked up two extra stitches in the "corners" at the bottom of the sleeve and did not pick up a stitch from the shoulder seam.

Also, place markers where the shoulder decreases start at the bottom of the opening.

Knit 9 stitches, move yarn to front, slip the next stitch, move the yarn to the back, change directions, [1] slip the first stitch (again,) and work back to the "beginning of the row," at the shoulder seam. Work the next nine stitches, slip the next stitch, move the yarn to the front, change directions, slip the first stitch (again), move the yarn to the back, and knit across.

When you get to a "wrapped stitch" at the end of this "short row," pick up the wrap and knit it together with the stitch it wrapped, and then wrap the next stitch.

Continue in this manner until you get to the markers where the arm hole shaping ends, before switching to knitting in the round for the main body of the sleeve.

[1]	You could turn the work, but I do this part just by knitting back backwards.

In addition to all of my other weird hobbies and practices, I have a minor fascination with and enjoyment of fountain pens, and have for a long time. After many years of not really writing very much long hand, I decided to get back to it a couple of years ago, and have amassed some pens, but perhaps more relevantly here, some opinions, which I thought I'd reflect on here.

A few notes and pieces of context first:

• I am left handed, which I think makes me more intolerant of slow drying inks, and pens that have unexceptional writing experiences.
• All of my long-hand writing is for myself. Aside from occasionally writing my name in the cover of a tune books, or something similar.
• I'm color blind, and have stayed away from ink colors in the red/purple spectrum, opting for mostly blue/black, blues, and blue-green, colors (with one exception.)
• None of these recommendations are sponsored. If you enjoy them, let me know!

So here we go.

• I mostly enjoy using Clairefontaine notebooks, mostly wirebound, and mostly as it turns out in the A5 size. I keep a steno pad on my desk for todolists and notes, and a side-bound notebook around for longer form notes.
• At least Somewhat to my own surprise, my favorite pens appear to be piston-filled German made pens with medium nibs. European pens tend to run more broad than average, and that's definitely true of my favorites:
  • Lamy 2000 is very modern looking and feeling, and it feels great to write with. The nib is very wet, so I've made a habit of using the quickest drying ink I have, and it's worked out well. If there's a complain, it's that the cap-seal is less than perfect if you are (as I am) an infrequent writer.
  • Pelikan m405 looks like a fountain pen, and while I suppose that's classic, and it is a very smart pen, I wasn't expecting this to be such a perfect pen. It's a joy to write with, the gold nib felt worth it, and the small size is actually an asset (I also have the larger m805, and find myself going for the smaller pen more often.)
• Also compelling are Namiki Vanishing Point which write really well. and are just really damn cool. The VP pens are great for regular use and short-bursts of writing. As a Japanese pen, the nibs run fine, and the gold nib versions are worth it. The Decimo version is great (smaller and thinner,) but the carbon-fiber ones are pretty compelling. I use the bladder converters, and I like them, but it's a bit weird. Namiki cartrages are great as well, particularly the blue-black ones and they're particularly easy to eye-dropper, if that's your thing. Additionally, I have a Lamy Studio with a fine (steel) nib that's way more compelling.
• Surprisingly compelling also is the TWSBI Diamond Mini and TWSBI Eco. I think I have a slight preference for the Mini over its larger version, and the Eco as well, but they're all great pens, particularly for the price, and as piston fillers, they're great if you're new to fountain pens or you want to have a color of ink available to you but not in regular rotation. The nibs are steel and you can tell, but it's not a huge detriment.
• The most compelling inks are, to my mind: Noodler's Q-Eternity, which is a nice blue-black color and dries really fast. Having said that, it's probably still second in my mind to Diamine Twilight, which also dries quite quickly, is a very similar color, and has really compelling shading. Thankfully there's no need to pick favorites.
• I have a short list of inks that I think are really good and worth being aware of if you're not. First Pilot's Standard Blue Black is a great ink, it dries pretty quick, the bottles are huge, and is somehow not super wet but also wet enough. I have a steel-nibbed Vanishing point pen, and this ink turned it from "meh" to compelling. I wasn't expecting to really like Diamine Oxblood which is a red-black ink, I suppose, but it's very nice. Finally, the Pilot Iroshizuku inks are very nice, and the colors are cool. I'm particularly fond of Tuski-Yo and Shin-Kai, but I suspect it's hard to go wrong.

That's it! I probably won't blog much about this, but would definitely be down to chat more about it, or pull together some posts if it's not too for you all.

I want to like test-driven-development (TDD), but realistically it's not something that I ever actually do. Part of this is because TDD, as canonically described is really hard to actually pratice: TDD involves writing tests before writing code, writing tests which must fail before the implementation is complete or correct, and then using the tests to refactor the code. It's a nice idea, and it definitely leads to better test coverage, but the methodology forces you to iterate inefficiently on aspects of a design, and is rarely viable when extending existing code bases. Therefore, I'd like to propose a less-dogmatic alternative: test-oriented-development. [1]

I think, in practice, this largely aligns with the way that people write software, and so test oriented development does not describe a new way of writing code or of writing tests, but rather describes the strategies we use to ensure that the code we write is well tested and testable. Also, I think providing these strategies in a single concrete form will present a reasonable and pragmatic alternative to TDD that will make the aim of "developing more well tested software" more achievable.

1. Make state explicit. This is good practice for all kinds of development, but generally, don't put data in global variables, and pass as much state (configuration, services, etc.) into functions and classes rather than "magicing" them.
2. Methods and functions should be functional. I don't tend to think of myself as a functional programmer, as my tendencies are not very ideological, in this regard, but generally having a functional approach simplifies a lot of decisions and makes it easy to test systems at multiple layers.
3. Most code should be internal and encapsulated. Packages and types with large numbers of exported or public methods should be a warning sign. The best kinds of tests can provide all desired coverage, by testing interfaces themselves,
4. Write few simple tests and varry the data passed to those tests. This is essentially a form of "table driven testing," where you write a small sequence of simple cases, and run those tests with a variety of tests. Having test infrastructure that allows this kind of flexibility is a great technique.
5. Begin writing tests as soon as possible. Orthodox TDD suggests that you should start writing tests first, and I think that this is probably one of the reasons that TDD is so hard to adopt. It's also probably the case that orthodox TDD emerged when prototyping was considerably harder than it is today, and as a result TDD just feels like friction, because it's difficult to plan implementations in a test-first sort of way. Having said that, start writing tests as soon as possible.
6. Experiment in tests. Somehow, I've managed to write a lot of code without working an interactive debugger into my day-to-day routine, which means I do a lot of debugging by reading code, and also by writing tests to try and replicate production phenomena in more isolated phenomena. Writing and running tests in systems is a great way to learn about them.

[1]	Sorry that this doesn't lead to a better acronym.

This is the follow up to Pattern Fragment 0, Pattern Fragment 1, and Pattern Fragment 2.

Starting at the "end" of the back of the neck, join new yarn, and with a short circular needle pick up stitches around the steek. Be sure to pick up the first/last stitch of the steek. If you did not set aside a stitch at the bottom of the neck, increase one stitch at the bottom point of the neck.

When you've completed picking up stitches and have knit (plain) across the back of the neck, begin knitting in Knit 1 Purl One Ribbing, being sure to mirror left-to-right at the bottom of the knit (i.e. if the last stitch before your "point" or "bottom of the neck stitch" is a knit, then you should knit the stitch right after the point.) Always knit the "point" stitch. Additionally, on this first row you should do a centered double decrease at the point.

My favorite centered double decrease is a "slip 2 together, knit 1, lift the two slipped stitches over the knit stitch."

Continue knitting the collar, in this ribbing, doing one double decrease every other row, for an inch and a half. Bind off normally.

It's not real secret that I'm red-green colorblind. It's not really a major life obstacle: I've got a wardrobe of clothes in colors that I can easily tell apart, I have developed a number of heuristics for guessing colors that are right enough, and mostly it just creates funny stories where I get a confused look if I try to describe something that might be purple, or have to convince a coworker into reading a graph for me.

One challenge historically, however, has been various kinds of text editing color themes: so often they end up having some kind of low contrast situation that's hard to read, or two different aspects of code that should be highlighted differently but aren't. I've tried lots of themes out, and I would always end up just going back and using default emacs themes, which might not have been great, but I always found it useable.

Until Protesilaos Stavrou's Modus Themes, that is.

These are super compelling and I never really knew how good an editor could look until I started using it. Like is this what it's really like for the rest of you all the time? Things are clear: I never get confused between type names and function names any more. There are rarely situations where I feel like the highlighting color and text color are the same, which used to happen all the time.

The real win, I think, is that Modus' makes dark themes accessible to me, in a way that they never were before. For the most part "dark themes" which have been so popular recently, are just impossible to see clearly (for me), I also find that it's less taxing to spend time in front of screens when darker backgrounds, so being able to spend most of my time doing work in an environment that's easy to read. I tend to keep to light backgrounds when using a laptop and dark backgrounds otherwise.

The second piece is that, I think I've caved in and decided to increase the size of the font, by default in my text editor, at least when I'm using my desktop/external monitor. I think my vision is as good as it's been, though I should probably get that checked out post-pandemic. I think there's a balance between "small fonts let you see more of the file you're working on," and "larger fonts let you focus on the area that you're editing." When I'm writing English, the focus is great, and when writing software I tend to want more context. There's a balance also in wanting to keep an entire line length viable at once, and an ideal words-per-line limit for text that's useful for making things easier to read. So there's some tuning there, depending on what your workload looks like.

I guess if there is any lesson in this it's that: Comfort matters, and you shouldn't push yourself into uncomfortable display situations if you can.