erydo

Not to imply any specific doubts—I’m aware of the narratives—but if you have references, I’m interested! Request, request.

This view is over-simplistic. Many—perhaps most—products are designed to serve more than one kind of user.

Obvious example: building an e-commerce platform. The merchant is a kind of user. The customer is a different kind of user on that same platform. Yes, they're humans, but they're not doing the same thing.

Any B2B or B2C type product will have at least two very distinct roles like that. And in those cases, arguing that everyone is just a person as a sort of moral position is destructively vague. It's more difficult to serve someone's needs if you can't start to narrow down what they're trying to accomplish.

While I totally agree with the sentiment that we shouldn't conflate personhood identically with their role in a product, solving useful problems does require that you de-scope and discretize the interactions a bit.

Congrats to the team. Though in the inevitable acquisition, I wish GitHub/Microsoft had been the acquirer: there are a lot of natural fits between that ecosystem and Keybase's model, and a reasonable history of successful acquisition.

Hopefully Zoom avoids gutting Keybase. I found it really useful for bootstrapping credentials when onboarding remote team members and contractors. Way easier to manage than GPG: it was fairly painless even for non-technical people.

Fingers crossed. I wonder what the infrastructure overhead cost is?

At some level I agree with your sentiment about shibboleth-style filtering. Not having seen these specific "tests" though, I can charitably imagine these being relevant to fault-tolerance/managed intricacy. Things like, "This code failed. How did it get to that state?" or "X can be interrupted at any time. Implement Y such that it atomically…" are examples of coding challenges that _are_ relevant to being fluent in embedded software development. I really doubt they're asking "implement quicksort"-type questions.

I care a bit. It's misleading by the standards of anyone who's used to reading graphs. Wikipedia is an organization I care about and trust and it sucks to skim a graph and realize that the axis was changed to mean something that the shape didn't convey. The entire value of graphs is using shapes to convey meaning.

That's true but still doesn't map here. Or at least, to my interpretation of it.

Stock-picking is specifically referring to where you should allocate a given amount if you are investing. There's obviously more to stocks than simply picking them, but as for picking specifically, there's no analog in poker because you don't divide your bet that way. (Aside from raising on a bluff, but that's stretching it).

Whether, when, and how much you should invest is a separate strategy that's related to your confidence and expected return of the picking strategy—but not the same thing.

Just like whether and when you agree to a game of chess vs tic-tac-toe might depend on your confidence in your skills; but that decision is _not_ relevant to chess strategy, which assumes you're already playing the game.

I believe the strategy comparison here is based on how to best allocate $X in the stock market.

Choosing not to allocate it is kind of irrelevant, just like "play tic-tac-toe instead" is not a chess strategy.

It's still just one definition: A paper map relates a point on a the piece of paper to a point in some other space (topography, subway stops, interstate routes, etc). And if you relax the "carto" part of "cartography" (e.g. someone working on OSM or Google Maps is still doing cartography), then I think cartography as "the practice of constructing maps" is still an unambiguous and non-overloaded meaning, which applies to mapping infrastructure just as well.

But, words are just words.

Mapping one's infrastructure is pretty common parlance. It's not even a pun, really.

I am even more of a layman than most here, but — why is it different? Isn't that basically Schrödinger's cat?

> There's a massive rift between "sun makes tree grow, preventing other trees from getting the light" and "I'm trying to sell my wares by expressing concepts of value, numbers, and desire".

Like a tree bearing bright red, juicy-looking fruits filled with sugar and vitamins?

Yes — won once, and died another time on the Plane of Fire. (I meant to zap down, not at myself! Damn. Learned to think before acting. NetHack is not as real-time as it feels when you're in a sticky situation.)

Just use the word that means the thing that you're talking about, as clearly as you can. What "clear" means depends on the context and audience.

It sounds like you probably already know this, but "fixed" and "constant" usually refer to concepts very distinct from "immutable". And "contextual function" would confuse everyone. (A monad isn't a function, and certainly not one influenced by some outer context). Similarly, "orthogonal" and "unrelated" aren't synonyms. (X and Y axes are orthogonal, but they're often related. That's why we plot things).

In every field, there will be people who over-use technical terms for status signaling. But those terms usually exist for a reason beyond that, and avoiding them as a sort of counter-signaling doesn't help anyone. It's just playing the other side of that game.

Usually the common term means the same things as a lot of things…that's both why they're common, and why they're less useful in a technical context.

Some other examples that come to mind are "electricity" (current, voltage, power…?); "size" (area, volume, mass…?). Just because an engineer or physicist might talk about volume doesn't mean you have to be a physicist to talk about it too. It also doesn't mean that, not being a physicist, the familiar word "size" means the same thing they're talking about.

Hey, this is really cool! Cross-language validation of data types is such a pain. This looks really well-done.

As a devil's…inquisitor, I guess— I'm curious what the reasoning has been behind the Navy's (and WWII RAF's) preference for split/seniority control and in what situations that balances out, if any. Are those situations where some known, serious risk of error is mitigated by sharing responsibility? Is betting on experience over skill actually wrong, or is their implementation misguided? Or just not applicable to those situations? (Fast situational awareness, etc)

It seems similar to the whole democracy v. autocracy tradeoff. One optimizing for coverage of perspective, the other optimizing for efficiency of a perspective.

Thank you!

What "nasty tactic" are you referring to? I see:

  Actually I was going to suggest that we work together and merge the best features of both into a common source-base that could be used by both groups going forward: eventually unifying the developer pool and mind share.  This might be difficult, but I think the end result would be useful.

Reaching out to another project with similar goals to clarify and understand the differences, and offer collaboration doesn't seem nasty. Am I missing something?

This is a really interesting topic that I know little about. This paper was published 36 years ago—is it still current with modern understanding of sailing? Or has anything changed or been refined significantly since?

Devil's advocate: Wouldn't a person who prefers sitting be more likely to keep a job as a driver rather than conductor?

An unhealthy person might think, "Ugh, I'd have to be on my feet all day." And a healthy person may not see that as a major negative.

At first I agreed with you, but realized that my preferred solution was essentially what they recommended and just with different wording. My thought process was:

  - Absolutely, DNS resolvers should not care or have knowledge of the protocol that will be used to access that address.
  - What they *should* do is just say that normal DNS resolvers shouldn't ever resolve .onion addresses.
  - (And then Tor should include a special DNS resolver that does anyway.)
  - Oh, that's compatible with what they said.

I think some of the confusion comes from their use of "applications".

My thoughts went straight to PostgreSQL Foreign Data Wrappers. Something like that would be really helpful!

Your own example is more concisely covered by arrows, which are already available:

  class Vector {
    constructor(x=0, y=0, z=0) {
      this.x = x;
      this.y = y;
      this.z = z;
      setTimeout(() => console.log(this.x + ", " + this.y + ", " + this.z), 10);
    }
  }

This is a really helpful way of describing the problem. Concretely describing behavioural coupling in terms of graphs is much less hand-wavy than the normal, "things become tightly coupled and which becomes hard to deal with."

Your example seems to assume translation only. I wonder how difficult/useful it would be to identify other kinds of time-varying characteristics (translation, rotation, scale, hue, saturation, brightness, etc) of partial scene elements in an automated way.

Along the same lines, it would be interesting to figure out an automated time-varying-feature detection algorithm to determine which kinds of transforms are the right ones to encode.

Do video encoders already do something like this? It seems like a pretty difficult problem since there are so many permutations of applicable transformations.

Preo Mobile Ordering | New York, NY | ONSITE | Full-Time | Multiple Roles | $50-150k (role- and experience-dependent) + bonus/benefits.

Preo has built the most advanced mobile ordering app and venue integration in the world: Order and pay for food and drinks from your phone, get an alert when it's ready, and never deal with a tab again. You never have to flag down the bartender at the club, waitress at the pub. We're rolling out in international markets with some very exciting new technologies and extremely powerful partnerships.

We're hiring to fill several roles, detailed in the postings on our AngelList page https://angel.co/preo/jobs. The salaries listed are base, on top of which we also offer an annual bonus based on personal targets, in addition to a longer term company target bonus pool. And benefits, of course.

We have several native Android products on both the customer and staff/operations side of things. We also have a fully native iPhone customer app in Swift, and mobile web app using React/React Router/Flux. Although we're willing to hire specialists, senior engineers who can contribute in multiple ways are always a plus. Specifically, if you're an Android or iOS developer who also has mobile web experience, you should apply.

Our backend is built out on AWS with Linux, Python, Flask, PostgreSQL, and other things. We're exploring some JVM-based technologies, Haskell, JavaScript, Haxe, etc. Someone with a combination of backend development/devops experience would be a great fit.

We're also looking for a more junior, full stack support role. Someone who would benefit from experience and exposure to a wide variety of things, and can help pick off the smaller-but-valuable engineering tasks that pop up. Small bug-fixes, intermediate feature work, and operations support. A little experience is helpful to show that you can learn, orient, and execute quickly, but this is expected to be more of a train-up role.

Finally, we're looking for a great project manager: someone who can help coordinate and track engineering, design, and operations scheduling. Previous experience, especially in software engineering, is required.

  * Android Engineer $80-150k: https://angel.co/preo/jobs/136209-senior-mobile-android-engineer
  * iOS Engineer $80-150k: https://angel.co/preo/jobs/136202-senior-mobile-ios-engineer
  * Mobile Web Developer $80-110k: https://angel.co/preo/jobs/136254-mobile-web-developer
  * Senior Backend and Infrastructure Engineer 100-150k: https://angel.co/preo/jobs/136248-senior-backend-infrastructure-engineer
  * Full Stack Support Engineer $70-110k: https://angel.co/preo/jobs/136268-full-stack-support-engineer
  * Project Manager $50-100k: https://angel.co/preo/jobs/136444-software-project-manager

To apply, contact me directly at [email protected] or through AngelList.

The `with` statement seems similar to Haskell's `do` notation for monads, where the monad(ish) here is pattern matching.

I'm new to Elixir but I've definitely run into the "byzantine case-clause" issue and it can be very annoying. My case was very similar to the example: pulling something from a form, validating the format, validating it in the database, and returning something. All failable, single-purpose functions in sequence to narrow down the result.

I grappled between using a monad macro library[0] to simplify `{:ok, _}`/`{:error, _}` signatures versus just raising exceptions. I ended up doing the latter for the additional benefit of stack traces. Exceptions seem culturally discouraged in Elixir, though I don't quite grok why yet.

Out of curiosity, would you be willing to show how you might refactor the post's "create_organization" example?

[0] https://github.com/rmies/monad

This is a small anecdote, but: I'm happy with my current iPhone and the current models aren't additionally compelling enough to me to upgrade.

I have an iPhone 5S and don't want a larger one. When the iPhone SE came out, I was excited until I found out it didn't have force touch, which was the main interesting feature to me about the new lineup. Other than Apple Pay it seems I have very little reason to upgrade until this one dies or breaks. I don't see being satisfied with their product as a black mark against them.

Never seen that before, that looks really interesting!

Agreed.

A common objection from new developers is that "commit messages are hard and they slow me down", so if that's how you feel (for example, you're starting a fresh project): go crazy with your commits and don't let them slow you down. But then rebase, squash, and edit the commits before sharing them.

If a developer consistently pushes commits like this, they should be guided by their team lead to understand their importance. But if over time they refused to improve them, in many cases that would eventually be fireable. Commits are the technical paper trail: whether used when diagnosing issues, merging, compiling release notes, or whatever. Making the messages clear is extremely important.

They did say "1.6x faster", not using the term "speedup" (which is terrible nomenclature too, but that's not the point).

To say that something that's no faster is identical to something that's "1x faster" is a terrible confusion of thought.

It's reasonable to expect that, for example, "1x faster" would mean "for a baseline of 1 operation per second, it's faster by 1 operation per second, i.e. a total of 2 operations per second."

EDIT: Oh god, that's even before I saw the "1.2x slower" entries…