jmillikin's recent activity

  1. Comment on I want off Mr. Golang's Wild Ride in ~comp

    jmillikin
    Link Parent
    The issue isn't what's in a string (Rust made the same choice), but by the Go APIs using string when they should have used an opaque FilePath type that can be semantically []byte on some platforms...

    The issue isn't what's in a string (Rust made the same choice), but by the Go APIs using string when they should have used an opaque FilePath type that can be semantically []byte on some platforms and []rune on others.

    Go's poor decision is because its designers didn't realize, or didn't care, that some platforms allow non-Unicode names in the filesystem.

    4 votes
  2. Comment on What's the Coronavirus like where you are? in ~talk

    jmillikin
    Link Parent
    They're not buying all the tissues, which would seem more relevant for a respiratory infection. Also little panic-buying of food; the cup noodles are a little scarce sometimes but all the staples...

    They're not buying all the tissues, which would seem more relevant for a respiratory infection. Also little panic-buying of food; the cup noodles are a little scarce sometimes but all the staples (rice, eggs, miso) are fine.

    It's only toilet paper.

    The head of a toilet paper manufacturer industry association (there's a phrase I never expected to write) published a press release saying there would be enough: https://www3.nhk.or.jp/news/html/20200228/amp/k10012306191000.html

    9 votes
  3. Comment on What's the Coronavirus like where you are? in ~talk

    jmillikin
    Link
    I live in Tokyo. People are emptying stores of toilet paper, like bare shelves. I have no explanation for this.

    I live in Tokyo. People are emptying stores of toilet paper, like bare shelves. I have no explanation for this.

    13 votes
  4. Comment on Increment Magazine, issue 12: software architecture in ~comp

    jmillikin
    Link Parent
    I work almost exclusively on the backend. If your development target has special constraints (like performance driven by browser capabilities), then adjust accordingly. It's still worth using...

    I work almost exclusively on the backend. If your development target has special constraints (like performance driven by browser capabilities), then adjust accordingly.

    It's still worth using Protobuf as essentially a schema language for JSON, since the default Proto<->JSON encoding is IMO reasonable. You don't need to worry about the data models of your TypeScript UI, Go middleware, and Fortran numeric kernel getting out of sync when they're codegen'd from the same source.

    3 votes
  5. Comment on Increment Magazine, issue 12: software architecture in ~comp

    jmillikin
    Link Parent
    I haven't read any of the others. I skimmed the two about code structure ("The rise of nanoservices", "A monorepo renaissance") and found them so discordant with my views on software that I...

    What do you think is the most interesting article in this issue, other than the one you wrote?

    I haven't read any of the others. I skimmed the two about code structure ("The rise of nanoservices", "A monorepo renaissance") and found them so discordant with my views on software that I couldn't get more than a few hundred words in. They will likely be grist for a future blog post.

    What's the most "haunted forest" codebase you've personally worked on?

    There are many that come to mind. Sharing full details would be both tedious and inappropriate, so I'll give a highlight from the two systems that motivated my original post:

    1. System A had a subcomponent for storing ticket comments -- just a flat list of short plaintext messages, indexed by ticket ID. The person who implemented it was a fresh hire with a PhD in databases. They wrote an N:M relational datastore from scratch, in Java, and exposed its full power via RPC. The "thread of messages" business logic was basically client-side in the UI. Massive API surface, terrible performance.

    2. System B was written in Ruby. One of the core data structures was a hash of active operations. One day, after a minor dependency update, it stopped working. Turned out the hash key objects had a field that (through a long dependency chain) included a Ruby magic thing equivalent to "all objects in the process". Something in the dep update caused an object, somewhere, to not compare equal to itself. This broke deleting items from the active operations hash.

    If you were starting a project from scratch, what principles would you try to follow to prevent your beautiful clean greenfield codebase from turning into a haunted forest?

    Data types -- whether the structs and interfaces of compiled code, or the RPC schema between processes -- are far more important than the implementation[0]. Spend a lot of time on the "outlines" of the system, and worry about coloring in the lines later. This doesn't mean you spend a month on UML diagrams, but it does mean you stop using string for every value that contains some sort of character data.

    Use a good build tool. People who have only ever used make/cmake/scons/etc have no idea how much influence a proper build tool can exert on system architecture though capabilities like codegen, enforced component boundaries, and rewarding good factoring through faster builds/tests. I believe Bazel is the best open-source build tool currently available (and I have used a lot of them).

    A lot of times you'll have a choice between solving a problem in a "fun" or "boring" way. At work, do the boring thing. You should feel drowsy just thinking about the tech choices. Even relatively "fun" tools like Kubernetes can be made boring with proper application of software engineering principles. Then go home and play with a prototype of the fun thing.

    The strongest tool in your cabinet for enforcing good architecture is the network. The second strongest is the process boundary. Avoid allowing details of the implementation language to leak outside of the process (e.g. as serialized cache files), and never let it leak onto the network (e.g. as language-specific serialization formats like Pickle or Gob).

    Try to combine these. For example, when picking a serialization format, Protobuf has a lot to recommend it:

    • Strongly typed and statically typed.
    • Integrates well with build-time codegen, which can define (strongly! statically!) typed client/server libraries in many languages.
    • Compared to JSON or ASN.1, Protobuf is about as exciting as a mid-day appointment at the DMV. Bounded integers, IEEE-754 floating point, and any string encoding you want as long as it's UTF-8.
    • Language-independent. A Protobuf-speaking service written in $A can be swapped out with one written in $B and none of the clients would notice.

    [0] The major exception here is for performance-critical code, where abstraction layers can cause enough indirection to miss performance targets. Even then, prefer a language like Rust (or the sane subset of C++) and lean heavily on zero-cost abstractions.

    4 votes
  6. Comment on Increment Magazine, issue 12: software architecture in ~comp

    jmillikin
    Link Parent
    I had previously written a version of it for my personal blog. It was popular in the internal Slack, and I was approached by the editor[0] about expanding it into a full article. Rewriting it took...

    I had previously written a version of it for my personal blog. It was popular in the internal Slack, and I was approached by the editor[0] about expanding it into a full article.

    Rewriting it took maybe ... 2-3 weeks? There was a bit of back-and forth between me, the reviewer, and the editor. Then it "went to print" and I heard ~nothing for three months.

    Somewhere along the line the title got changed. I'm not fond of this one; feel it misses the metaphor. The rest of the editing suggestions were useful.

    [0] I work at Stripe, which publishes Increment.

    5 votes
  7. Comment on Increment Magazine, issue 12: software architecture in ~comp

    jmillikin
    Link
    I contributed one of the articles in this issue; AMA?

    I contributed one of the articles in this issue; AMA?

    5 votes
  8. Comment on Stop using encrypted email in ~comp

    jmillikin
    Link Parent
    The article is about what can be used today, with existing technology. It also goes into some depth about why the user experience of email (e.g. searchable long-term archives) is difficult (or...

    While it would require an entirely different protocol than email, there would seem to be no fundamental reason why a messaging system with email-like messages could not be just as secure and easy to use as Signal or Matrix. It simply doesn't exist right now.

    The article is about what can be used today, with existing technology. It also goes into some depth about why the user experience of email (e.g. searchable long-term archives) is difficult (or impossible) to reconcile with secure communications.

    And while I use age personally, CLI-only utilities are not reasonable secure alternatives to email. I can easily get other board members to use Signal. It's unlikely many of them would even know what a command line is.

    I bet you could get them to host PDFs in a secure document management system, or even just Google Drive. If you absolutely need cryptographic signatures, Acrobat has that feature: https://helpx.adobe.com/acrobat/using/securing-pdfs-certificates.html

    1 vote
  9. Comment on Stop using encrypted email in ~comp

    jmillikin
    Link Parent
    I think you've misunderstood the author's position. Encrypted email should not be used, because it does not provide the security benefits the user believes they're getting. For the use case of...

    stop saying instant messengers are a suitable replacement for encrypted email.

    I think you've misunderstood the author's position.

    • Encrypted email should not be used, because it does not provide the security benefits the user believes they're getting.
    • For the use case of "email for short private messages", a secure short-message application like Signal is a reasonable alternative.
    • For some other use cases (the article specifically mentions secure file transfer), Magic Wormhole or Age are good choices.

    For your specific goals:

    • If you have a document that you want to send out, and don't need it to be secure against government-level surveillance, unencrypted email would be fine. There is no need to PGP internal corporate memos.
    • If you want to create an unencrypted document with a cryptographic signature, prefer PDF (or OpenDocument/Word, or RTF, etc).
    • If you want to carefully control access to a sensitive document, send it via a link to a separate document-management tool that supports proper ACLs. Google Drive (or equivalent for whatever vendor you're using) works well for this.

    E2E encryption would be useful, even disregarding state-level adversaries. For example, an E2E-encrypted system would allow users to have conversations without concern that the system's administrators could access them. Consider personnel discussions regarding the administrators, for example.

    See, this is why the article is written. Your belief that encrypted email protects you against a hostile mail server sysadmin is plausible, and true in certain extremely limited circumstances, but generally wrong.

    Speaking as someone who has done some amount of sysadmin work:

    • A person with admin-level access to your local workstation (e.g. the IT department with corporate-managed device) also has, or can trivially obtain, access to all data you view with it.
    • Even if your IT policy allows reading work email on a personal device, it is extremely difficult to protect your emails from someone with access to the mail server -- see https://efail.de/ for one recent example.

    If you want to talk about downsizing the Exchange admin, then you should have that conversation over Signal.

    4 votes