capn_duck

I agree that this would work, and be ideal. I think it only scales to a certain size organization though. At my company, I'd guess we have over a thousand developers across hundreds of teams, and more supporting staff. There's no possibility of getting everyone in at once.

The 16 pings a minute. The 6 hours of meetings a day because people aren't getting the information they need organically each day. The "hey, can I call?"'s during what I thought would be my free half hour in the afternoon. This is definitely not what it was like in the office.

Unfortunately, I recognize this doesn't change unless an org goes 100% back onsite.

The JS examples don't seem too demonstrative to me. Especially for someone not very familiar with RxJS. Any time you're wrapping something with `from` or `of`, I raise an eyebrow

  export function pipeline(in$: Observable<Product>): 
  Observable<string> {
      return in$.pipe(
          mergeMap(product => from(product.Images)),
      );
  }

Why use mergeMap at all here? Why not not just

  return in$.pipe(
    map(product => product.Images),
  );

I get that this is a toy example, not trying to be pedantic.

Thank you. I guess I was imagining that the flags lived in your source code repo, and required a commit and push to update, thus triggering some CD build and redeploying your app anyways.

This is my question. If your flags are in your repo, what is functionally the difference from just having them be variables in your code somewhere.

"Feature Flags that live inside your code" - That's just variables, no?

This is peak Hacker News response

I interpreted the parent comment in the inverse. A poor economy means people will stay in unhappy situations longer than otherwise.

I've always been unsure where this stuff fits in. Do you make it before your system is built, when its unclear how where all the cards will fall? Or after your system is made and in production and all the warts of reality are present and your graph is not so nice and neat anymore. This seems like an architects picture of things. Close enough to give people the false confidence to think they understand things, but not close enough to be of use to anyone actually working in the salt mines.

This is the second comment I've seen in this thread comparing "Gitflow" to what was typical in SVN. Having been there when SVN was in vogue, I can assure you that our process looked nothing like Gitflow. SVN encourages what we now refer to as "trunk based development". The default branch was even called "trunk".

My experience was that older VCS's (SVN in my case) leaned in heavily to the trunk based paradigm. I don't know what you're talking about with prod branches. The default branch in SVN was called - trunk.

This one blog post resulted in so much pain for so many. I'm glad it has been addended, but the damage was done.

For the record, I don't think it's the authors fault.

doesn't is suffice to say that functions meet all the prerequisites of a vector space?

f + g = g + f

f + (g + h) = (f + g) + h

f + -f = 0

(a * b) * f = a * bf

a (f + g) = af + ag

(a + b) * f = af + bf

I read this book too and it really drove things home. I remember after feeling a little bit unsure about the relevance of orthogonal systems, feeling the thrill of beginning to see and anticipate where the argument was going. It felt like I was discovering it for myself. I think there are lot of good math and physics books from the Soviet era.

If they are limited to 1, then they are not appropriate to use as a deployment mechanism. Do you only have one change being worked at a time? On my team, there's typically at least have a dozen different stories being worked in parallel.

Okay dude!

Bias is how all electric components work. All they know about is the difference in voltage between their electrodes, not any absolute voltage w.r.t the rest of the circuit.

Yes yes yes. You're not going to get much appreciation of this from newer devs. They've only known one thing. I shudder at all the human-hours spent on duplicative tasks related to the artificial frontend/backend separation.

nah its ml bro

That makes sense. Thank you.

Honest question - What would you do to justify doing this over using cookie based sessions? Like, are there back of the napkin calculations you could do to find when one approach becomes comparable in performance to another? That's one thing in system design that I struggle with.

Can you explain what this looks like? So each application that authenticates its requests using the jwt subscribes to a message queue and replicates the data in some database local to it? Then it checks that database each time a new request comes in?

It's not as if you're expected to use ORMs to do ad hoc querying of a database. Just fire up a db connection and start writing sql.

If you work on a large application with lots of transactional processing, it makes sense. I've worked on apps with 10's of 1000's of lines of Ibatis scripts. And on applications where you're expected to just invoke stored procedures for every little operation. I'll take Hibernate over that situation any day.

People really overstate the pitfalls of ORM's. If you're running reports against a data warehouse, don't use an ORM. If you are trying to optimize a complex query, don't use an ORM. For an app that is write heavy, with very many simple updates to a complicated object graph, it makes sense.

Are you confusing software dependencies for the semantics of a running program?

You're talking about the role that transistors play as switches in a digital logic circuit. The video is about the physical operation of, in particular, bipolar junction transistors, which are more commonly used as amplifiers.

I'd strongly recommend it! I think it's worth the price of admission for the first few chapters alone, although I admit that at a certain point, I was struggling to keep up with all of the mathematical arguments as I am not a trained physicist. But I was able to keep up by hand through all of the thermodynamic, electromagnetic, and statistical mechanical arguments of the black box portion.

But the first few chapters are so conversational and grounded in historical context that it's a real joy to read, even if you're not following along on pen and paper through all of the steps. If you know of any other "must reads" of the 20th century like this, please let me know! I love to hear the arguments presented as they were actually discussed at the time, not just what was settled on as the end result a century later.

Wow, I feel like this article was written for me. I too just recently stumbled upon the significance of Planck's work while reading David Bohm's "Quantum Theory". It was such a pleasing thing and wasn't too difficult to follow at all. It uses classical electrodynamics to get an expression for the energy contained in the box with respect to frequency, which of course disagrees with experiment. Then he supposes that energy could only be transferred in certain chunks, and uses statistical mechanics to show what the new distribution looks like.

As you say, the existence of photons wasn't immediately jumped to. All that he deduces is that energy transfer must be quantized, and this is the real insight of quantum mechanics, but it gets lost in the woo-ey clickbaity world of modern pop sci.

It was so nice to read the derivation from the point of view of a contemporary 20th century physicist, made me want to start reading a bunch of other 20th century physics papers in their original form.

I've honestly never understood this argument. There's some changes that are intractable. Just being in a separate codebase doesn't mean you don't need to deal with it. Team A just modified their service to require a new field in a request? Now you just have Teams B-G having to play a card to update their corresponding code if they consume that service. And unless you have everything feature flagged across all teams in a consistent way, or are very careful about API versioning, you'll all need to release at the same time anyways. Nothing magical about microservices solves this, no?

This is like a meme in software development reposts and I hate it because it just says "things can go wrong with component X of your system". It doesn't say when, it doesn't say what the threshold is. There's no equations, no direction for someone that hasn't dealt with one of these problems before. It's less than useless.

I strongly disagree that Lisp syntax is straightforward. Racket/Scheme is decent, but Common Lisp and other Lisp-2's can be incredibly confusing. Having different value and function namespaces for symbols is complicated enough, but the worse problem is that the simple evaluation rules don't always apply.

The base case is simple enough, the symbol-function value of the first symbol in a list is looked up, the rest of the arguments are evaluated or self-evaluated, then passed in to the function. The problem is that when the first symbol is a macro, you need to remember which of the following arguments are evaluated, or taken as unevaluated forms. Anyone who thinks this is easier to parse because there's less syntax either has too little experience with Common Lisp, or is kidding themselves.

In particular I was talking about parser/compiler formalizations made in the 50's/60's with the participation of the linguistic community. Kleene stars and their connection to regular languages, the Chomsky hierarchy, pushdown automata and table construction to make efficient bottom up parsers. And the benefits and confidence that these formalizations can provide to the programmers implementing these systems to the point that today, parser generators are an afterthought. No one would try to implement a parser today using a pile of if/then statements or well, those that do will probably find the road to enlightenment after some initial pain and then some googling.

This isn't Math in the sense of numerical computing or solving partial differential equations. But its a better and more natural abstraction to work from. We've figured out the types of graphs we require to express our computations, and we've figured out the language representations that generate those graphs, as well as efficient methods to generate those graphs given an input language and a sequence of sentences. Add to that all the rich developments of type theory.

The Photon/Hyperfiddle thing seems to me to be somewhat similar. It's declarative approach, let the compiler figure out all the cut points and join points, and just stop worrying about it. I'm sure if you looked at their source code, you'd find a lot of code concerned with walking the program tree and coloring different sections, then transforming those sections in a context-dependent way in to something that can run on a server versus a client with well defined interactions.

Barbers definitely need to keep current and I know for a fact attend meetups and workshops or whatever you want to call them to learn new and fashionable techniques. Seems like a weird comparison to make in an article that impresses humble beginnings.