Too long have I had my dwelling
  among those who hate peace.
I am for peace,
  but when I speak, they are for war!

— Psalm 120:6-7, ESV

I am for peace.

Our current president terrorizes Pakistani residents with imminent drone attacks and uses those same drones to murder U.S. citizens.

His chief contender takes the administration to task for “seeking to reap a ‘peace dividend’” when we are supposedly “not at peace”.

I needed a command line argument parsing library for Scala. Most of the existing ones either didn’t support subcommands, had strange APIs, had strange semi-standard parsing behavior, or weren’t very clean to use from Scala. The best I’d found, JCommander and JewelCLI, both had their own limitations, and JewelCLI at least was difficult to use from Scala due to namespace collision with its @Option annotation.

I found argparse4j, though, and was quite taken with it. It is modelled after Python’s argparse module, which sets the bar in my book for power and sanity in argument parsing APIs. It had all the power I was seeking — subcommands, GNU-style option parsing, automatic help generation, etc. — but the API wasn’t particularly fluent to use from Scala.

So I wrapped it up in a bit of Scala to produce argparse4s. There are some code examples in the README; basically you just write down options you want using flag, option, and argument methods, and then you can retrieve their values using an implicit execution context handed to you by the outer parsing and invocation logic.

It also makes use of type classes to automatically handle type conversions and default metavariables, so if you have option[String]("delimiter"), it will have a default metavar of “ARG” (or something like that), while an option[File]('o', "output-file") will have a default metavar of “FILE”. It will also automatically handle type conversions (hooking into argparse4j’s type conversion logic, and doing a few things of its own). And, of course, you can define the type class for your own types so that you can have options of any type you want.

One of our favourite dishes is fish & chips. One of the perks of living in Toronto for a summer was having a cheap fish & chips place just a couple blocks away. And here, there’s a great place (Mac’s Fish & Chips) a couple miles from our apartment.

But often we make our own fish & chips. The first, key thing is the batter. After some experimentation, here’s the recipe I use:

• 1C flour (usually white, occasionally add some whole wheat)
• 2t cornstarch (helps the consistency a lot, helps it stick to the fish)
• Seasoned salt (I just sprinkle some on; usually use Harley’s)
• 1 egg
• Milk (we use coconut or rice milk, but dairy milk works as well of course. I recommend 2% or whole; skim might be a little thin)

Mix together flour, cornstarch, and salt with a fork. Mix in the egg. Then add milk a bit (~1/4C at a time), mixing with the fork, until it’s a good consistency. You want it thick, thick enough it doesn’t drip all over the place, but not so thick you can’t spread it over the fish.

I’ve been bearish on Do Not Track. Providing user control over tracking is useful, but DNT has seemed to have exactly zero utility, being the Internet-tracking equivalent of the evil bit. Trackers have little incentive to use it, short of regulatory pressure or just trying to be good people, and the particularly bad actors who I might really want to keep my data away from are never going to respect it even with regulation. So turn on RequestPolicy and forget about it.

Then this crossed my radar. Twitter is personalizing the new-user experience based on tracking data collected via tweet buttons, so your new account automatically has suggestions of people to follow that might actually be relevant. This has huge implications for improving experience for new users; a lot of the benefit of Twitter depends on the streams you follow, and connecting users to relevant streams right off the bat seems like a great way to dramatically improve the quality of the initial experience and thereby improve user retention.

Thanks in part to Do Not Track, Twitter is also building this feature in the most responsible way I can imagine:

• If you have Do Not Track set in your browser, they don’t track your data.
• They purge data after 10 days, so they don’t hang on to it indefinitely and your new-user experience is only based on the last 10 days of web visits.
• They describe the feature, and the data they collect.